Consider updating to a newer Sphinx and relaxing the constraints
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- python
- Domain
- build-system
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.
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!
- Dominant language
- Python
- Stars
- 3.8k
- Forks
- 898
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing 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.
More from mapillary/OpenSfM
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Potential compatibility issues with matplotlib.cm.get_cmap (Incompatible with Matplotlib 3.9.0)Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Issue with ODMOpen
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 30/100
All issues in mapillary/OpenSfM
Similar issues
-
bug status/needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
prowler-cloud/prowler#12887 · 1 comment ·
Maintainers usually reply within 1 day
-
area: desktop platform: macos priority: p3 status: ready type: enhancement
Difficulty 1/5 Under an hour Newbie friendliness 92/100
use-agent-os/agent-os#3484 ·
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
open-telemetry/opentelemetry-python-contrib#5113 · 2 comments · 2 reactions ·
Maintainers usually reply within 1 day
-
external
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
langchain-ai/docs#6255 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day