Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

No dependency floor in pyproject.toml is tested

Open
  • Is something wrong?
#25 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
github-actions, python
Domain
build-system, ci-cd, testing

Research direction

Start with pyproject.toml and the existing test.yml, docs.yml, build.yml, and release.yml workflows, then review how floors.txt constraints interact with normal and isolated installs. Add a Python 3.11 CI leg that exercises the declared minimums, and add the described wheel metadata assertions where appropriate; done means the suite passes at the floors and the assertions distinguish the supported Hatchling versions.

Written by the indexing model from the issue text.

Description

pyproject.toml declares eight >= floors. None of them is tested — every CI
leg installs the newest of everything, so each floor is a claim nobody has
checked.

Declaration Where Exercised by CI?
lxml>=5.0 dependencies No — pip install -e .[dev] takes the newest
hypothesis>=6 dev No
lxml-stubs>=0.5 dev No
pytest>=8 dev No
pytest-cov>=5 dev No
mkdocs-material>=9 docs No — docs.yml takes the newest
mkdocs-static-i18n>=1.2 docs No
mkdocstrings[python]>=0.27 docs No
hatchling>=1.27 build-system No

requires-python = ">=3.11" is the exception, and is well covered: test.yml
runs a 3.11 leg on ubuntu and windows, [tool.mypy] python_version = "3.11"
type-checks against it, and CONTRIBUTING tells developers to develop on it. The
exact pins (mypy, ruff, build, twine) enforce themselves.

lxml>=5.0 is the one that matters to users: it is the only runtime dependency,
and the floor is a public compatibility promise. Nothing has ever installed
lxml 5.0 against this test suite.

Proposal

One CI leg on the Python floor that installs the declared minimums and runs the
suite:

  floors:
    runs-on: ubuntu-latest
    # python-version: "3.11"
    - run: python -m pip install -e .[dev] -c floors.txt
    - run: python -m pytest

floors.txt lists each declaration as == (lxml==5.0, pytest==8.0, …).
pip has no --resolution lowest — that is uv — so a constraints file is the
mechanism. The build-backend floor needs PIP_CONSTRAINT instead, since it is
resolved into build's isolated environment rather than the install
environment.

Expect this to fail at first and to move some floors up. That is the point: a
floor that fails is a floor that was wrong.

Related: the license-metadata assertion

Hatchling before 1.27 builds this project's wheel without complaint and emits
license = "MIT" as a legacy free-text field, dropping License-Expression and
License-File; twine check passes that wheel (see #24). A floor alone cannot
catch it, so build.yml and release.yml want a step asserting those two fields
are present in the built wheel — about nine lines of YAML each, verified to pass
a 1.32.0 wheel and fail a 1.26.3 one. It belongs with this work rather than
ahead of it: it would otherwise be the only enforced package floor in the file.

Dominant language
Python
Stars
1
Forks
0
Avg merge
9d 14h
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sillsdev/python-sil-lift

All issues in sillsdev/python-sil-lift

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.