In Nixpkgs, since opensfm's requirements.txt pin its dependencies to the patch versions (e.g. Sphinx==4.2.0), we've been just shipping opensfm with relaxed constraints, effectively dismissing the requirements.txt. Right now have to patch opensfm's setup.py ad hoc, so as to account for Sphinx's interface changes.
It'd seem however, there shouldn't be any particular reason for opensfm to keep sticking to the old version? Would it also be possible to consider pinning major or minor versions of the dependencies instead? Additionally, if these were pinned via the project.dependencies in pyproject.toml (cf. https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html), the pep-517 frontends would automatically verify these constraints. Setuptools would also export all of that information in the .dist-info, which might be useful for other projects
SomeoneSerge
commented
9 months ago
Hi! It'd seem that
sphinx.setup_commanddoesn't exist since7.0:In Nixpkgs, since opensfm's
requirements.txtpin its dependencies to the patch versions (e.g.Sphinx==4.2.0), we've been just shipping opensfm with relaxed constraints, effectively dismissing therequirements.txt. Right now have to patch opensfm'ssetup.pyad hoc, so as to account for Sphinx's interface changes.It'd seem however, there shouldn't be any particular reason for opensfm to keep sticking to the old version? Would it also be possible to consider pinning major or minor versions of the dependencies instead? Additionally, if these were pinned via the
project.dependenciesinpyproject.toml(cf. https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html), the pep-517 frontends would automatically verify these constraints. Setuptools would also export all of that information in the.dist-info, which might be useful for other projectsThanks!