You seem to have gotten things backward in who is the one asking for work to be done for free here. You are not talking to people that are asking you to work on software for free, you are talking to the people (many unpaid) that maintain a service that you want to use (again, for free), the General registry. The guidelines are put in place are there to try to ease their job and to provide an improved experience for users. The particulars of the guidelines can of course be discussed but a “my way or the highway” attitude is not going to be very productive for anyone.
17 Likes
At this point, I actually don’t care about submitting software to the registry anymore. I am considering just doing my research work in private.
There’s always extra work when something breaks, no matter how compatibility bounds are structured. There’s active work in reducing that workload — especially for the case where the breaks don’t hit your usages.
https://github.com/bcbi/CompatHelper.jl
Other language ecosystems have used similar bots to help packages update their dependencies. I’ve not used this yet, but it should be as simple as an auto-generated PR — and if tests pass, it’s an easy merge.
5 Likes
But it is still more work and more complicated for the package author.
If I understand @chakravala correctly, he wants his package to go from v1, 2, 3… and just state dependencies A, B, C without further bother except for known incompatibilities in past versions.
I have sympathies! By chance just yesterday I watched his Juliacon presentation and I suppose a lot of very very hard work is needed for such research and packages like Grassmann or Dendriform.
With such commitments maybe there is no time/will/motivation left for package tagging hassle. – Would be great, if the General registry could support such use cases at some point in future. @chakravala likely isn’t the only one who wants to have it simpler.
1 Like
@kristoffer.carlsson @fredrikekre I agree that better tooling would address my concern above with “near-miss” situations. I also like the idea of being able to switch off the resolver sometimes or at least relax the constraint on some packages when resolving to quickly test out if a certain combination of versions is indeed feasible or not.
@StefanKarpinski I don’t agree with this statement. Those people could be contributing good publicity at the very least. And if they stick around for long enough, they might start contributing in other ways. Those people could also be contributing to other packages but don’t have too much time to investigate the issue at hand because of some deadline or something.
Anyways, thanks for everyone’s responses, and I hope we can all stay constructive in our criticism and criticism of the criticism.
1 Like
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
I hate to contribute to the general acrimony here, but I have to say that since I’ve made this post, the more time I get to think about this, the worse I feel about where this is all going.
Let me just paint the same picture I have several times on slack:
A year from now, when most packages have these bounds, suppose you must have 2 or 3 of your direct dependencies fully updated, but you can’t get them to do this because of some conflict somewhere up the dependency graph where you can’t easily see it. If everybody did everything perfectly, it means that if you land yourself in this situation, it’s because those packages you are asking for are simply incompatible. My question is, does everyone think this is really the most likely cause for such a situation? It seems to me far more likely that the cause is someone somewhere either neglecting to update the bounds in one of their compats (which currently seems extremely easy to do) or somebody having tagged a “breaking change” when the changes were in fact either non-breaking or minimally breaking. Your alternatives at this point frankly suck: you can try to track down the issue and make PR’s to all the relevant packages, you can use your own forks, or you can use your own repository like @kristoffer.carlsson’s “LivingAtHead”.
I’m trying here, but I’m having a really hard time imagining upgrading Julia packages to be anything but an absolute nightmare in a world where everyone is strongly incentivized to have compat bounds for everything, but there is anything less than immaculate tooling for doing so. I’ve already outlined the above scenario several times, and nobody has given me any reasons why I should not expect it, I fear because everybody thinks it’s the likely outcome.
So that this is more than mere complaint, let me suggest the following (likely to be very unpopular) course of action:
- Stop requiring
compatbounds for auto-merging in General, leave it entirely up to users to place bounds. - If it some point the tooling exists to do so, have a bot make PR’s to place the bounds in the original package and in General whenever a tag is made.
I’ve heard lots and lots of arguments why the current requirements are reliable on the assumption that everybody is very diligent in updating the bounds and properly tagging releases, but I’ve yet to hear any arguments as to how we can expect everyone to do this. That’s not an afront to package authors, but really who can maintain this? Are people going to go back to their packages every couple of weeks, lift the bounds, and update them? No, that’s not going to happen. Everything is going to get stuck, and with the Julia ecosystem being “young” for the foreseeable future, this could really significantly worsen the quality of life of everyone working with the language. CompatHelper.jl is great, but I really think we need something more integral to the process.
I’ve resisted writing such a gloomy post, but at this point I really want somebody to convince me that the above is not going to happen. For what it’s worth, I’m already dealing with downgrades myself, still don’t know where they’re coming from, and seem to have identified at least one case of an inappropriate bound.
18 Likes
What exactly would be the ideal? Automatic SemVer registry? Where upper bounds are automatically generated from CI test results? Wouldn’t that be best?
1 Like
I think one of the solutions to this problem would be to have the resolver list very clearly which packages have upper bounds that do not correspond to the latest release of a package. That way people can easily complain to these packages or make PRs to raise upper bounds, or remove these packages (possibly by using a separate environment).
17 Likes
I am a strong believer of the selected strategy. I just wanted to let you know you are doing amazing work.
I hope this will encourage package authors to release v1.0.0 of their packages. SemVer works best if it is used correctly and let the major number roll as well.
5 Likes
I thought the same. This would embrace both opinions / use cases:
- normal foundational packages which fully resolve and have reproducibility
- research packages with less guarantees but also less hassle to the author(s)
A package author could choose 2. (but the default would be 1.) And when ] add ing a research package, a warning would be displayed.
3 Likes
I agree with @ExpandingMan’s revised opinion.
At a minimum, either default path (incentivizing version ceilings or sticking with the previous pattern) needs to still easily enable the other, e.g. a way to easily bypass version ceilings at either the environment or package level, or to force apply last-known-good configurations at the env/package level.
As-is, this is almost guaranteed to generate a lot of stale packages (in the sense of them stuck using 2-year-old dependencies), and more importantly, installation headaches. It is a great policy for any enterprise development or repeatable analysis work, but feels overly conservative for the type of high-velocity community (in terms of both development speed and iteration of popular libraries) that Julia has already fostered…
1 Like
Thinking this to the end, maybe two registries are needed (as has been discussed many time before):
-
General(as we have it now) with no mandatory Compat-bounds (and no encouraged ones by auto-merge) -
Curatedwith Compat-bounds (as well as other quality assurances)
1 Like
I don’t understand the need for YAR (yet another registry): we all agree that SemVer is great but we are worried that authors won’t diligently update the upper bounds on their dependencies. Surly the solution should therefore be to automate the upper (and lower) bounds of our dependencies? Assuming our test suits are ok, wouldn’t that be “trivial”?
7 Likes
I think we understand @nalimilan’s suggestion differently: my reading is that it is about making the resolver emit more information so that these things can be tracked down easily.
IMO a lot of issues coming from tighter compatibility bounds will just be resolved by tooling, which at the moment does not exist or is experimental. Because of this, I think that projecting the consequences of these requirements on the current situation results in an unnecessarily bleak picture.
Let’s wait for the tooling before evaluating the consequences.
7 Likes
to automate the upper (and lower) bounds of our dependencies?
But you would still need someone to merge the PR after the bounds are adjusted. Maybe the author is on a three month field-trip, or maybe taking a break, or too busy, or something. Having to wait 3 weeks until a dependency lock-down is sorted, might be too long. And I don’t think you can request that a package author is around all the time, also, I would guess that many packages have only one or few with commit access. For a package in a “Curated” registry, however, such requirements could be in-place.
Assuming our test suits are ok
This is not a requirement of the General registry either, I think.
2 Likes
I would go as far as automatically merging those. I mean, if all my tests pass for all these versions just by changing the number in the [compat] section in the Project.toml file then surly that’s fine. It is possible that this method will let something through, but it would be identical to a human checking it out. The worst case scenario would be identical to a case where a human set the upper bound to too high and someone found out in the wild.
As to the test suits, we all are behind increasing the test coverage as it is, so that should be ok.
2 Likes
Yes. It was not rare in 0.6 that just adding a set of packages from a fresh install didn’t work because one of them had released a semver incompatible version. This state was broken until someone that had the know-how fixed it. Most people just give up at that point (as I do, if I try a Python package and it just doesn’t work). At that point (0.6 and earlier) it wasn’t that bad because the number of packages was quite small so a person with knowledge how to fix things tended to find the problem quite quickly but with rapid expansion in the number of packages this will not happen.
You could look into making a --force-latest PR towards Pkg that turns off the resolver and just gives you the latest versions of everything. It should just be a couple of lines.
Having to wait 3 weeks until a broken state (packages not working with each other even though their compat claims to) is sorted out might be too long as well and then it affects everyone using the package, not just the ones that require the latest version.
So you rather have code that installs but (perhaps silently) doesn’t work? Why would the 2 year old code still work if it’s dependencies have released multiple backwards incompatible versions. By luck?
9 Likes
And just to point out, when an author tags x+1.0.0 or 0.y+1.0 the intent of doing that is for dependees to not automatically use that version. Not having upper bounds goes against the author of the package intents. There might be reasons for this but it should in my opinion not be the default.
For me, it is very important that a new user coming and doing add A B C D should get a set of working A, B, C, D. Getting handed a non-working set of packages gives an extremely bad impression. Having other types of (non-default) modes where you opt in to e.g. ignoring bounds is of course possible, someone with the will just have to implement it.
Also, the bottom line is, if we have an ecosystem where packages get backwards incompatible changes all the time, things will suck no matter what.
12 Likes
I feel one argument we can stop addressing is the fact that this:
is the goal and that SemVer is the means.
We also agree that a situation where many packages are very stalled because of too tight bounds is suboptimal.
So the questions are:
- Is this fear completely unrealistic, are people worried for nothing?
- If this fear is real, what exactly should we do about it, how can we mitigate this?