So I maintain a few small packages. Lately, their dependancies have shuffled around because the ecosystem is chugging along (woo!). But, when I go to use one or two of my packages I run into compatability issues.
How do you all keep compat issues straight? Naively I keep thinking changing compat to always use the tilde specifier is reasonable, but, surely that could break over time.
Is it “ok” to cut a new release just to update a bad compat section?
Yes, it’s even encouraged! As a good package developer, you should generally try to keep your dependencies up to date. The CompatHelper.jl GitHub action is really helpful for that.
You also mention that you use the tilde specifier for your compat entries. Generally, you should prefer the caret specifier (you can leave the caret off), unless you have reason not to, since that will give you the compatibility behavior as specified by semver and you will have to bump your compat entries less. See also 6. Compatibility · Pkg.jl.
Appreciate the advice Simeon. I’m going to start using the caret operator from here on out. It’s crazy realizing how fast the community has moved over the past year.
… follow-up on this.
#TL;DR: How come a clean Project.toml with but a Julia dependency works amazing?!
With my package PolyChaos I was careful to check compatibilities. Recently, a pull request asked for a change, and things started to go down… So in a somewhat desperate act I removed every compat entry in the Project.toml except for Julia, and guess what – it works like a charm?!.. Can somebody plese explain? Is it because I was overly constraining compatibilities?!.. I guess when a package is installed on a clean distribution (as is the case for Travis), then the julia package manager is smart enough to figure everything out? Apparently, it’s smarter than my humble self, because it used to be a pain to keep compat entries up…
Possibly in the sense that the resolver will just figure something out for you, but keep in mind that any of those packages could release new, breaking versions, in which case your code will break.
It is really best to specify compat bounds. Also, note that the General registry requires this.
The point is that “will break” is a too strong assertion. Your code may or may not break from a breaking change in a dependency, depending on whether, and sometimes how, you use the specific functionality that changed in a backwards incompatible way.
The only ways to determine whether you need to change something in response to a breaking dependency change is to review your code against the breaking changes in the dependency, or if you have a good enough test suite that you trust, run it and see that it passes.
Just assuming that you will never be affected by breaking changes by removing all compat is too optimistic though. That may work for a while but sooner or later it likely won’t, but neither you, nor your users, will know when that happens. If you’re lucky things will fail in some loud and obvious way. If you’re unlucky results will become silently incorrect.
The automerge process for the General registry will indeed complain about unbounded dependencies, for good reasons.
To be sure — if, for example, the breaking change is in part of the API not used, then it is innocuous.
However, in practice, given that
omitting compat bounds will break code with very high probability in the medium run.
It is really best to specify compat bounds. Also, note that the General registry requires this.
I fully agree!
Given that the the resolver figured out correct dependencies, couldn’t I just look at what package versions the resolver used and copy those to my Project.toml? In other words: specify the union of all resolved package versions in my Project.toml?
As far as I can tell your compat bounds before https://github.com/timueh/PolyChaos.jl/pull/51 were perfectly fine. The problem reported in that PR was that PolyChaos 0.2.3 wasn’t compatible with StaticArrays 1.0 and therefore couldn’t coexist with versions of other packages that required it. But you already had the StaticArrays compat bumped on master, so the only thing needed was to register a new version or the user adding PolyChaos#master. The dropping of StaticArrays compat was completely irrelevant to the compat conflict.
I.e., I would suggest just reverting the compat changes and release a new version or instruct people to use the master branch for the time being if version 0.2.3 isn’t compatible enough for their uses.
Thanks so much for helping me out with this, @GunnarFarneback. I’ll take a look and keep you posted via GitHub.
This is a big shout out to the amazing Julia community: I had a problem and you helped me fix it. Isn’t that sweet? Thanks a lot @GunnarFarneback and @ChrisRackauckas for making the recent PolyChaos v0.4.2 release possible!