Implement option to yank/blacklist a release. #726

fredrikekre · 2018-09-07T13:18:30Z

Implement support for yanking versions in a package registry.

Very WIP, but this allows us to blacklist releases on the registry level. They can not be installed, but they can still be used, and you can instantiate a Project.toml + Manifest.toml with it, so it should not break working code. Here https://github.com/fredrikekre/Registry/blob/97919d39c95a3d917ea3b69e78aad68c7c02bf7c/I/ImportMacros/Versions.toml I have blacklisted version 0.2.0 of ImportMacros, and consequently:

(v1) pkg> add ImportMacros
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
  Updating registry at `~/.julia/registries/Registry`
  Updating git-repo `https://github.com/fredrikekre/Registry.git`
 Resolving package versions...
  Updating `~/.julia/environments/v1/Project.toml`
  [13b54a02] + ImportMacros v0.1.0
  Updating `~/.julia/environments/v1/Manifest.toml`
  [13b54a02] + ImportMacros v0.1.0

installs version 0.1.0. But we can instantiate a Manifest.toml with version 0.2.0 in it:

(v1) pkg> st
    Status `~/.julia/environments/v1/Project.toml`
→ [13b54a02] ImportMacros v0.2.0
┌ Warning: Some packages (indicated with a red arrow) are not downloaded, use `instantiate` to instantiate the current environment
└ @ Pkg.Display ~/dev/Pkg/src/Display.jl:190

(v1) pkg> instantiate
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
  Updating registry at `~/.julia/registries/Registry`
  Updating git-repo `https://github.com/fredrikekre/Registry.git`
 Installed ImportMacros ─ v0.2.0

fix #355

fredrikekre · 2018-09-07T13:49:24Z

Some questions:
Is Versions.toml a good place for this? Feels like it, but perhaps it is better to have it formatted like

["0.1.0"]
git-tree-sha1 = "..."

["0.2.0"]
git-tree-sha1 = "..."
yanked = true

which is also backward compatible.

What should happen on up? Currently ImportMacros will be downgraded to 0.1.0.

00vareladavid · 2018-09-08T01:26:02Z

up's behavior seems reasonable to me. What would happen on add ImportMacros@0.2.0?

KristofferC · 2018-09-08T01:47:16Z

Exactly the same as if the yanked version was not in the registry?

fredrikekre · 2018-09-08T16:51:55Z

What should happen if A depends on B@v0.2 and B@v0.2 is yanked?

KristofferC · 2018-09-08T17:09:25Z

Probably wouldn't allow yanking that release in that case.

fredrikekre · 2018-09-08T17:31:21Z

So that should be checked on registry CI then.

simonbyrne · 2018-11-27T04:27:36Z

you can instantiate a Project.toml + Manifest.toml with it, so it should not break working code

In some cases, wouldn't you want to break the code if it has been blacklisted (i.e. if the code was malicious?)

fredrikekre · 2018-11-27T19:55:11Z

Triage: In favor, but recorded in the registry as #726 (comment) rather than fredrikekre/Registry@97919d3

fredrikekre · 2018-11-27T23:55:39Z

bors try

fredrikekre · 2018-11-28T00:01:37Z

Should be good to go now, but would be good if someone could review the calls to load_versions and see if I got the include_yanked = (true|false) correctly.

bors · 2018-11-28T00:49:18Z

try

Build failed

continuous-integration/appveyor/branch

fredrikekre · 2018-11-28T13:52:25Z

bors try

bors · 2018-11-28T14:35:13Z

try

Build succeeded

KristofferC · 2018-11-28T21:32:35Z

src/Operations.jl

@@ -77,7 +80,7 @@ end
 function set_maximum_version_registry!(env::EnvCache, pkg::PackageSpec)
    pkgversions = Set{VersionNumber}()
    for path in registered_paths(env, pkg.uuid)
-        pathvers = keys(load_versions(path))
+        pathvers = keys(load_versions(path; include_yanked = true)) # ??


Probably false here.

Ok, what does this do? So we can add a test

It is for backward compatibility with 0.6 stuff so not sure we need to add a test really. It just sets the version to the maximum one in the registry, only used when no Project file is present.

StefanKarpinski · 2018-11-28T21:58:39Z

I wonder whether we should have this include_yanked option at all? Do we need it for anything?

fredrikekre · 2018-11-28T23:46:36Z

Do we need it for anything?

We need to collect yanked versions when instantiating a Manifest (I think).

fredrikekre · 2018-11-29T00:00:16Z

... but maybe we can go look directly for the tree hash instead of first collecting all versions

StefanKarpinski · 2018-11-29T19:38:28Z

If it complicates things not having it, keeping is fine, I was just wondering about it.

fredrikekre · 2018-12-02T16:01:53Z

bors try

bors · 2018-12-02T16:35:44Z

try

Build succeeded

fredrikekre · 2018-12-03T23:54:37Z

If it complicates things not having it, keeping is fine, I was just wondering about it.

Let's leave it there for now, can be revisited.

bors r+

726: Implement option to yank/blacklist a release. r=fredrikekre a=fredrikekre Implement support for yanking versions in a package registry. 938: better error message when we cant find uuid in manifest r=fredrikekre a=KristofferC This should not really happen but it seems to happen anyway, so at least give a better error message for it. Co-authored-by: Fredrik Ekre <ekrefredrik@gmail.com> Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com>

bors · 2018-12-04T01:37:01Z

Build succeeded

fredrikekre added the triage label Oct 18, 2018

fredrikekre force-pushed the fe/yank branch from 134368c to 759ac3e Compare November 27, 2018 21:28

bors bot added a commit that referenced this pull request Nov 27, 2018

Try #726:

8d4ea89

fredrikekre changed the title ~~[WIP] Implement option to yank/blacklist a release.~~ Implement option to yank/blacklist a release. Nov 27, 2018

bors bot added a commit that referenced this pull request Nov 28, 2018

Try #726:

dc94f14

KristofferC reviewed Nov 28, 2018

View reviewed changes

Remove yanked releases when collecting available version.

5478b90

fredrikekre force-pushed the fe/yank branch from f8690f5 to 5478b90 Compare December 2, 2018 16:01

fredrikekre added registries Pkg's handling of package registries and removed triage labels Dec 2, 2018

bors bot added a commit that referenced this pull request Dec 2, 2018

Try #726:

f054fa7

bors bot merged commit 5478b90 into master Dec 4, 2018

bors bot deleted the fe/yank branch December 4, 2018 01:37

fredrikekre mentioned this pull request Feb 26, 2019

Blacklist compat specifier #1089

Open

fredrikekre mentioned this pull request Nov 2, 2019

What to do after renaming a package? JuliaRegistries/General#4917

Closed

mkitti mentioned this pull request Dec 15, 2021

Yank JLD 0.12.4 JuliaRegistries/General#50601

Merged

LilithHafner mentioned this pull request Aug 10, 2022

1.0 release jw3126/Setfield.jl#146

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement option to yank/blacklist a release. #726

Implement option to yank/blacklist a release. #726

fredrikekre commented Sep 7, 2018 •

edited

Loading

fredrikekre commented Sep 7, 2018 •

edited

Loading

00vareladavid commented Sep 8, 2018

KristofferC commented Sep 8, 2018

fredrikekre commented Sep 8, 2018

KristofferC commented Sep 8, 2018

fredrikekre commented Sep 8, 2018

simonbyrne commented Nov 27, 2018

fredrikekre commented Nov 27, 2018

fredrikekre commented Nov 27, 2018

fredrikekre commented Nov 28, 2018

bors bot commented Nov 28, 2018

fredrikekre commented Nov 28, 2018

bors bot commented Nov 28, 2018

KristofferC Nov 28, 2018

fredrikekre Nov 28, 2018

KristofferC Nov 28, 2018

StefanKarpinski commented Nov 28, 2018

fredrikekre commented Nov 28, 2018

fredrikekre commented Nov 29, 2018

StefanKarpinski commented Nov 29, 2018

fredrikekre commented Dec 2, 2018

bors bot commented Dec 2, 2018

fredrikekre commented Dec 3, 2018

bors bot commented Dec 4, 2018

Implement option to yank/blacklist a release. #726

Implement option to yank/blacklist a release. #726

Conversation

fredrikekre commented Sep 7, 2018 • edited Loading

fredrikekre commented Sep 7, 2018 • edited Loading

00vareladavid commented Sep 8, 2018

KristofferC commented Sep 8, 2018

fredrikekre commented Sep 8, 2018

KristofferC commented Sep 8, 2018

fredrikekre commented Sep 8, 2018

simonbyrne commented Nov 27, 2018

fredrikekre commented Nov 27, 2018

fredrikekre commented Nov 27, 2018

fredrikekre commented Nov 28, 2018

bors bot commented Nov 28, 2018

try

Build failed

fredrikekre commented Nov 28, 2018

bors bot commented Nov 28, 2018

try

Build succeeded

KristofferC Nov 28, 2018

Choose a reason for hiding this comment

fredrikekre Nov 28, 2018

Choose a reason for hiding this comment

KristofferC Nov 28, 2018

Choose a reason for hiding this comment

StefanKarpinski commented Nov 28, 2018

fredrikekre commented Nov 28, 2018

fredrikekre commented Nov 29, 2018

StefanKarpinski commented Nov 29, 2018

fredrikekre commented Dec 2, 2018

bors bot commented Dec 2, 2018

try

Build succeeded

fredrikekre commented Dec 3, 2018

bors bot commented Dec 4, 2018

Build succeeded

fredrikekre commented Sep 7, 2018 •

edited

Loading

fredrikekre commented Sep 7, 2018 •

edited

Loading