Please be mindful of version bounds and semantic versioning when tagging your packages

Second real life example: a student of mine had code he wanted to show me but my packages were all out of whack. My first reaction was to not even try: from prior experience (from before embracing strict versioning) there is bound to be some incompatibility in the packages that breaks code designed under a different configuration of package versions. I pressed ahead and, yes, there was 5 annoying minutes of trying to get Pkg to actually add and update the right packages, eventually requiring deleting all the packages and adding them one-by-one so they were on the right versions.

But the nice part: once the packages were added the code actually worked! Because there were strict upper bounds, once the pkg system was happy it was safe to assume the packages were all compatible. 5 minutes of dealing with Pkg being annoying is preferable to 5 minutes of compile time with packages all over the place, only to realise the package versions used are not quite compatible and having to manually try to track down a compatible set of package versions.

It would be good if Pkg made it easier to get into a “good” state: it’s annoying having the message “cannot add package due to the following 20 lines of package dependencies”. But this is a small (and hopefully temporary) price compared to what things were like before.

5 Likes

You can remove the manifest, and then Pkg will be forced to resolve again. Also, on Julia 1.4 Pkg is a bit more flexible when resolving (https://github.com/JuliaLang/Pkg.jl/pull/1330) so you should hopefully see this type of errors less often.

12 Likes

I have just released 1.0.0 of a package.
I changed the compat section in Project.toml from

[compat]
julia = "≥ 0.7.0"

to

[compat]
julia = "0.7.0, 1"

Is this the action which is expected for automatic merging?
(Just asking this, because of some confusion I have now, not meant as discussion or opinion.)

Yes, but all dependencies need to have upper bounds.

1 Like