CI: add a pixi job - conda-forge python/deps, linux aarch64 - #884
Conversation
2005a6f to
99f05bf
Compare
| platforms = ["linux-aarch64"] | ||
|
|
||
| [dependencies] | ||
| meson = ">=1.12.0,<2" |
There was a problem hiding this comment.
Is there any reason to pin meson to this versions range?
There was a problem hiding this comment.
Not really, we can replace it with *, we'll get the latest version in the lock file either way, unless the resolver does something very strange. This is more documentation than anything.
There was a problem hiding this comment.
I also thought that this is more documentation than anything, thus it would need to be more nuanced that this. Maybe simply * is best.
There was a problem hiding this comment.
The <2 is even more interesting than requiring a minimum of the just-released version. :)
Meson currently has no plans for a semver major 2 release, in the sense that we will undoubtedly want to make one someday but it is quite unlikely to be any time soon. It will surely drop deprecated functionality leading to breakage, but only for projects that don't deal with deprecation warnings for years...
In general this kind of rolling "you get a few years to handle deprecations" approach to compatibility is something I think is nicer than pinning to major versions (even if I also like SemVer :P). It would be slightly disappointing to to see <2 locking start happening in general -- is this something the tooling automatically defaulted to, or ...?
There was a problem hiding this comment.
is this something the tooling automatically defaulted to, or ...?
I don't know for this specific case, but pixi defaults to this kind of version ceiling when adding a package to a workspace. I don't like it either, but it is a very popular thing to do.
There was a problem hiding this comment.
Yes, it's the default behavior you get from pixi. It pins minor versions for 0.x version numbers, and major versions for >=1 numbers. This kind of choice is always controversial no matter what one chooses exactly. Given that pixi is language-independent and handles compilers, C libraries, etc. it seems like a reasonable choice to me to not blindly go over major version boundaries when a user runs pixi update.
For Python packages I agree, not a fan. But there we don't typically worry about ABIs etc., nor is SemVer all that common.
In general this kind of rolling "you get a few years to handle deprecations" approach to compatibility is something I think is nicer than pinning to major versions
✅
There was a problem hiding this comment.
This could be
meson = ">= 1.2.3"
to match a simplified version of what is in pyproject.toml but I am fine with the * too.
There was a problem hiding this comment.
Yeah I thought about it, but then it might goes out of sync again, so I'm happy with *.
One minor annoyance: this requires adding a REUSE.toml, because by design the fsfe/reuse tool doesn't support ignoring files in a simple way: https://reuse.software/faq/#exclude-file
3 participants
I decided to run this job on a Linux aarch64 runner, so we get some more variety for free here - we weren't testing on that platform at all, other jobs all use
ubuntu-latest.One minor annoyance: this requires adding a
REUSE.toml, because by design https://codeberg.org/fsfe/reuse-tool doesn't support ignoring files in a simple way: https://reuse.software/faq/#exclude-fileCloses gh-847