Pkg.jl: Blacklist compat specifier

[oxinabox]

It would be good to be able to specify versions of a package that are Not to be installed.
E.g. MbedTLS 0.6.7 is broken.
Lets say that MbedTLS 0.6.8 has been released which fixed it.

And lets also say we already rule like ^0.5, ^0.6
The rule one wants is to say "please do not install 0.6.7".
Right now the way we can't express that the allowed version is
0.5.0 <= v <=0.6.6 || 0.6.8 <= v <0.7.0

I can imagine having a ! rule that comes after all other rules, seperated say by a semicolon,
which could allow us to write the above as
^0.5, ^0.6; !0.6.7

I guess allowing this kind of rule make solving the constraints a bit more fiddly.

By SemVer 2 rules, one can not fix a broken release and republish it as the same version number.
I think we are in general handling this kind of thing at the registry level, by untagging that release, but it should be handle-able at the Pkg level also.

[fredrikekre]

https://github.com/JuliaLang/Pkg.jl/pull/726

[KristofferC]

I think we are in general handling this kind of thing at the registry level, by untagging that release, but it should be handle-able at the Pkg level also.

Yeah, I think this should still be handled on the registry level since if the release is broken then it is broken for anyone. They yanking in #726 allows to do this while keeping existing manifests working.

[oxinabox]

Yes, I think handling it in the registry is definitely desirable.
But the Pkg level we want also.
We want both.
Since various things may prevent the registry being updated.
Including but not limitted to:

• Prolonged argument as to if the thing is actually broken.
• Working from a registry snapshot,
• Working from a registry that is poorly maintained.
• the need to do this immediately (I feel like you've made other mistakes if you end up in that situtation, but still)

[fredrikekre]

Putting this in Project.toml would only work for in-development packages or projects though, since it won't be reflected in the version bounds for already released versions of the package. At that point, isn't it easier to just not install the version you know are broken instead putting this in a constraint and then resolve?

[oxinabox]

Because working out by hand what is an allowed version can be hard.
That is why we have package managers.

For something like MbedTLS it can be particularly hard.
From given project using my package Foo.jl, might use say:

• Foo --> MbedTLS
• AWSCore --> HTTP --> MbedTLS,
• DataDeps --> HTTP --> MbedTLS
• HTTP --> MbedTLS
• CloudWatchLogs --> MbedTLS

So if I just set a partiocular version of MbedTLS in Foo.jl,
I might well make it hard for this project with its 5 seperate dependency chains to MbedTLS to resolve.
Foo itself might similarly have those other 4 paths,
and the same point applies.

[fredrikekre]

I don't understand, why can't you just pkg> add MbedTLS@$(WORKINGVERSION)?

[oxinabox]

Because I don't know what version is working and is going to be compatible both with all my current dependencies and with the dependencies i might add or change tomorrow.
And this applies both to my package and to projects using my package.

It working out a possible version for everything was easy we wouldn't need the resolver part of the package manager.