I fully agree. I prefer to have too tight bounds and maybe having to ping a package author to release them in order to use the newest features, instead of having packages (silently) break, because a dependency moved to a new version (just happend to me now with the release of ZygoteRules v0.2.0).
4 Likes
Actually, there can be a lot of reasons that’s not fine. Some things are very hard to test using CI, like
- GPU functions
- visual plot tests
- performance regressions that do not show up in tests on CI servers
These situations might thus depend on the package author running tests on a local machine and setting compat bounds accordingly.
If a automatic compat adjustment was merged, it could break one of the things that are not tested on CI and are only tested locally.
1 Like
I agree. Add a mechanism that will allow for manual adjustments of bounds.
Arguably, running the test suite and bumping versions, or just reviewing the results and merging with automated tools mentioned above, is the lowest cost maintenance imaginable for a package.
Consequently, if a package fails to be updated for a long time (eg a few months) despite outstanding PRs for compat version bumps, then it is very likely to be (at least pro tem) abandoned and compat bounds might be least important concern for its users.
If people consider such packages valuable and worth maintaining, then they should just
- ask nicely to be added as a maintainer (most package authors are willing to do this),
- failing that, fork the project.
2 Likes
So we…agree? Tools is the solution. How automated they are, or how exactly they should work, is besides the point. But a bleak future where everything is stalled, locked to some old version, etc, will be avoided with tools.
This is a good point. And even if the package is abandoned but still perfectly good for all existing versions, we can fork it (as you’ve mentioned).
1 Like
I am not sure we agree. My position is roughly the following:
-
Tools are important, and should reduce the cost of maintaining compat bounds significantly, potentially to zero (for those who opt-in to some automated setup).
-
Getting a smooth workflow with these tools may take some time and experimentation. We should be patient and keep an open mind in the meantime. (And trust that in the unlikely case this experiment does not work out, the devs maintaining the General registry will backtrack and figure out a solution instead of dooming the package ecosystem — they have a very good track record so far).
-
Once maintaining compat bounds has a small cost, packages which don’t do it despite requests should be considered abandoned in practice. From that point, the question is more general than compat bounds (ie how to deal with abandonware). The fallback option of having some set of versions which still works will be valuable in that scenario.
-
How the above tools work is not “beside the point”, it is very important.
-
I consider a scenario “where everything is stalled” entirely hypothetical and unrealistic. I am not sure that apocalyptic visions really help this discussion.
6 Likes
Awesome. I for one agree with most of what you said. Sweet!
1 Like
Hi all,
I’d like to clarify the current workflow. Suppose I have released a package for which I have set the upper bounds on all direct dependencies. Am I supposed to “follow” the dependencies via GitHub so that I get notified of any new releases. Then, when I see a SemVar breaking release, I ought to check if it actually breaks my package. If it doesn’t, I should bump the upper bound and register a new release.
Is my interpretation correct?
Best wishes,
Zygmunt
There could be exceptions within automatized system where user does provide compat bounds. But that should not be encouraged!
Maybe not, but currently, all packages that have any sort of GPU capability require additional steps above and beyond Travis CI to test everything fully. That is quite a lot of packages…
Fully agree.
This said, I think this can be compatible with a research package G which doesn’t declare upper bounds: when doing ] add G, Pkg asks for confirmation (‘do you really want to install this’) and the user has the option to think again and accept the risk of incompatible changes in future. Also when the resolver fails due to G it could print that a non-standard/research package is involved.
While tooling may help, I’d like to know when a package goes that route and depends on auto-magic.
What would happen to packages that are denied entry in the General registry? Would they be scattered all over Github? One couldn’t ripgrep ‘~/.julia/packages’ any more and find it?
In that case a separate registry as mentioned by Mauro might be nice (I would keep ‘General’ strict regarding upper-bounds and choose a name like ‘Non-Standard’, ‘Relaxed’ or so for missing upper bounds).
Ok. Then for every package which depends on GPU package directly or indirectly developer could specify a compat bound for that particular GPU package. Perhaps additionally such policy would be suitable for UI frameworks, plotting packages where writing a test is not trivial. But it should not be plied for pure Julia packages where dependency comparability can be determined from the test itself.
AFAIU, yes, your interpretation is correct. However, as has been mentioned multiple times is this thread, this arguably time consuming effort should (I’d even say must) be facilitated by a bot that (at least) does the “following” part for you. The bot would look out for according to semver breaking releases of dependencies and will automatically create a PR at your package that you might/should bump your version. It then boils down to you checking/merging this PR which I expect to almost be a no-brainer in many cases.
2 Likes
Why this valid suggestion is neglected? If you don’t care that your package will break, why don’t you set the upper limits in the way they won’t restrict your users anyway?
I will repeat myself, but I really like the selected strategy and I am strong believer it’s the right strategy.
FWIW, I made a short script that look at bounds in the registry (discussing with real data at hand is usually more productive than with hypothetical data). The results can be seen here: https://gist.github.com/KristofferC/7c8048e2ee9aaa465966caeb98c1446a
The first list is all packages that are bounded to not be at their last version from any source at the source’s last version (basically, at least one package in the registry has for its latest version an upper bound that is not the latest version of that package) and the number of packages that are upper bounding them.
The second list is all packages upper bounding any other package not to the latest version and a list of these pacakges.
ACME => ["StaticArrays"]
for example means that ACME upper bounds StaticArrays to not its latest version (which it does https://github.com/JuliaRegistries/General/blob/master/A/ACME/Compat.toml#L20, and latest StaticArrays is 0.12).
The last file is the script to produce the output.
So if you wonder why you don’t get the latest version of a package, you can just Ctrl-F it there and it will find the packages upper bounding it.
33 Likes
Data-Driven conversations - thanks!
This lined up with some issues I’ve had with dependencies, especially with SpecialFunctions (w/ 8), for example:
Distributions => ["SpecialFunctions"]
Did simple search for “SpecialFunctions” and it’s interesting to see all the threads about issues with dependencies for this, both pre and post v1, seems to be another hot one.
Much respect to all here for both their patience and prescience in suggested approaches.
This bot will do the “following” and “notifying” for you: GitHub - JuliaRegistries/CompatHelper.jl: Automatically update the [compat] entries for your Julia package's dependencies
6 Likes
This all sounds useful, but I may not even continue using github for a long time, I may host my repository elsewhere eventually, what happens then? This solution depends on github.
I would prefer something like a script I can run locally, instead of an automated github bot, in addition with an email notification that doesn’t necessarily depend on github itself.
It’s a bad idea to have all this stuff totally depend on github.
6 Likes
I fully agree. To expand on my earlier comments against opening upper bounds, here’s my recent experience.
I have a set of packages for my lab, with an internal registry. I also have a meta-package that runs the tests on all of these packages in one fell swoop. I ran that testset about 6 months ago, and all was green.
I’m now setting up a new box (we run mostly Macs here, but this one is Manjaro. Thanks, @ExpandingMan!). Installed all packages, ran the testset (three weeks ago), and broken tests in something like 80% of my code. Mind you, I hadn’t touched any of that core code in the last 6 months. After digging in, I can tell you that nearly all of the problems (80-90%) were because of an open upper bound specified within one or more of my dependencies (where I depend on A.jl, but A.jl depends on any B.jl >= something).
The remaining problems were cases where I had missed entering my own upper bound in a direct dependency, but those were easy to fix because I’m directly familiar with that code.
Claiming that you are compatible with all future versions of Foo.jl is simply incorrect. You may be compatible with future Foo.jl, once it’s written, but until you have it in front of you, you don’t know.
5 Likes