Consider updating to a newer Sphinx and relaxing the constraints
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 3.8k
- Forks
- 899
- PR merge metrics
- No merged PRs in 30d
Description
Hi! It'd seem that sphinx.setup_command doesn't exist since 7.0:
- https://github.com/sphinx-doc/sphinx/blob/v6.2.1/sphinx/setup_command.py
- https://github.com/sphinx-doc/sphinx/tree/v7.0.0/sphinx/setup_command.py (doesn't exist)
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
Thanks!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing requirements.txt and setup.py, then compare the current dependency constraints with the Sphinx interface changes described in the issue. Check whether pyproject.toml is present and how dependencies are currently declared. Done means newer Sphinx versions are supported, constraints are intentionally relaxed, and the package metadata expresses the required dependencies consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100