Relax pyproject.toml requirements?

[oneorseveralcats]

Would it be possible to switch the == to >= in pyproject.toml?

I'm considering packaging python-libzim for nixpkgs, because pyglossary depends on it for zim input. The only thing is the dependencies in pyproject.toml necessitating an exact version (==) has made trying to package it not really work. I have issues with trying to do the current version because it requires package versions that are newer than in nixpkgs.

I switched to trying to package a previous point release version (3.11.0), so that I can test the package I'm writing for build errors but I get version errors:

 > ERROR Unmet dependencies (checked against /nix/store/d64q19q1xjdwfhqx6czvrjgrhq0n3lcc-python3-3.14.7/bin/python3.14):
>        cython==3.2.4
>           wanted: ==3.2.4
>                 found: 3.2.5
>    setuptools==82.0.1
>              wanted: ==82.0.1
>                found: 83.0.0

I knew that python-libzim was probably packaged in either arch or the aur and looked at the package build and the packager there just uses sed to replace == with >= in their PKGBUILD. (here)

[rgaudin]

I support relaxing the requirements but those are not runtime dependencies but build ones so it's arguably easier to control.

In your example though I see your setuptools is on the next major. By definition, we'd probably not relax it to allow a future major so that wouldn't work. For effort reason, it would likely be '>=82.0.1,<83` in this case. Would that suit your use case?

Also, those number are older those on what's on last release.

[oneorseveralcats]

Yeah that would work.

I ended up going back two releases because, for some reason, cython 3.2.8 isn't packaged on nixos yet (which is required for 3.12.0). It seems like they merge all python related package updates to a different branch and test for regressions and issues before merging a lot of python package updates all at once.

The main reason, I was looking at older releases is because I haven't actually packaged anything for NixOS and was trying to get a version that had its dependency requirements met so I could see if I was, in general, doing the packaging right. I'm probably going to wait to submit an actual package until the most up-to-date release of python-libzim will build and install on NixOS.

[benoit74]

I'm not sure to get the detailed rationale for opening these dependencies range.

I do get the problem you are facing, and agree it is a real one.

But at the same time our policy of pinning dependencies is meant to ensure we have stable builds, and to express a clear contract on what we can reasonably ensure to be working fine.

Runtime dependencies of shared libs like this repo must be as wide open as possible for obvious reasons. Build dependencies are another beast IMHO, and I'm concerned opening them too much will aaskf

I'm OK to open a bit like setuptools >=82.0.1,<83, but I feel like while it is OK on this particular case, I'm pretty sure we will get other issues asking for "more".

[oneorseveralcats]

Nixpkgs is the largest package repo and installing stuff from it is supported on NixOS, most Linuxes, MacOS, Android, etc. so it feels very efficient to contribute stuff to it. Development on it is rolling release, so libraries are relatively up to date, so I don't think it would require opening the range any further than has been proposed here (for my specific use case).

Also, given that this hasn't really come up before, the fact that most people probably use python tools that sidesteps the issue, and the only place I've seen seen that packages it is unofficial (Arch User Repository) and just overrides the dependency versions (which violates the guarantees of upstream), I don't really understand where the motivation for widening the supported versions even further would come from.