Relax pyproject.toml requirements?
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- build-system
Research direction
Start in pyproject.toml by reviewing the dependency entries that use exact == constraints, then compare them with the packaging concern described for Nixpkgs and the Arch PKGBUILD linked in the issue. Done means the dependency declarations support compatible newer versions without breaking the package's stated requirements; verify the package can be built with the versions available in the reported environment.
Written by the indexing model from the issue text.
Description
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)
- Dominant language
- Python
- Stars
- 109
- Forks
- 29
- Avg merge
- 9d 1h
- Merged PRs (30d)
- 1
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.
More from openzim/python-libzim
-
Release 3.14.0 Opentask
openzim/python-libzim#267 · 1 assignee ·
-
Code review: writer-path use-after-free, sys.modules corruption, GIL held across all reader I/O Open
Difficulty 5/5 Over a week Newbie friendliness 35/100
openzim/python-libzim#266 ·
-
Build for ABI3 Openenhancement
Difficulty 4/5 3-5 days Newbie friendliness 48/100
openzim/python-libzim#264 · 1 comment ·
-
enhancement upstream
Difficulty 4/5 3-5 days Newbie friendliness 25/100
openzim/python-libzim#241 ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 30/100
openzim/python-libzim#240 ·
All issues in openzim/python-libzim
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
syfoud/Simulated_Scepter#172 ·
-
A cancelled tests run makes the coverage comment workflow fail and reports it as a red check on main Openarea: ci bug perceived difficulty: 3
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Nitjsefnie-Harness-Commons/daedalus#921 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
EleutherAI/lm-evaluation-harness#4207 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ClickHouse/clickhouse-connect#1057 ·