Subcategory: Dependency hygiene — 3 → 8
What I found
Runtime dependencies are declared in three places that disagree with each other:
| Package |
setup.py INSTALL_REQUIRES |
requirements.txt |
| scipy |
>=1.16.1 |
>=1.13.0 |
| cvxpy |
>=1.6.6 |
>=1.7.2 |
| scikit-learn |
>=1.3.0 |
>=1.7.0 |
pyproject.toml [build-system].requires adds a third set (numpy>=1.26.4, scipy>=1.13.0, setuptools==78.1.1, pybind11==2.13.6).
The disagreements point in both directions — setup.py wants a newer scipy than requirements.txt, and an older cvxpy and scikit-learn — so neither file is simply stale. An installed wheel and a pip install -r requirements.txt dev environment can resolve to different, individually-valid dependency sets.
pyproject.toml also has no [project] table, so standard tooling cannot read the dependency list at all:
$ uvx deptry riskfolio
Found 47 dependency issues. # all DEP001 "imported but missing from the dependency definitions"
Those 47 are largely an artifact of there being no declarations to compare against (riskfolio is the package importing itself; sklearn is scikit-learn unmapped) — but the artifact is the finding: no tool can audit dependencies here.
There is also no lockfile, and every pin is a >= floor with no upper bound.
Files to change
pyproject.toml — add a [project] table carrying the runtime dependenciessetup.py:INSTALL_REQUIRES — read from the manifest or removerequirements.txt — regenerate from the manifest, or scope it to dev-only tools
done when…
Runtime dependencies have exactly one source of truth, uvx deptry runs clean against it, and the three files no longer state different floors for scipy, cvxpy and scikit-learn.
Subcategory: Dependency hygiene — 3 → 8
What I found
Runtime dependencies are declared in three places that disagree with each other:
setup.pyINSTALL_REQUIRESrequirements.txt>=1.16.1>=1.13.0>=1.6.6>=1.7.2>=1.3.0>=1.7.0pyproject.toml[build-system].requiresadds a third set (numpy>=1.26.4,scipy>=1.13.0,setuptools==78.1.1,pybind11==2.13.6).The disagreements point in both directions —
setup.pywants a newer scipy thanrequirements.txt, and an older cvxpy and scikit-learn — so neither file is simply stale. An installed wheel and apip install -r requirements.txtdev environment can resolve to different, individually-valid dependency sets.pyproject.tomlalso has no[project]table, so standard tooling cannot read the dependency list at all:Those 47 are largely an artifact of there being no declarations to compare against (
riskfoliois the package importing itself;sklearnisscikit-learnunmapped) — but the artifact is the finding: no tool can audit dependencies here.There is also no lockfile, and every pin is a
>=floor with no upper bound.Files to change
pyproject.toml— add a[project]table carrying the runtime dependenciessetup.py:INSTALL_REQUIRES— read from the manifest or removerequirements.txt— regenerate from the manifest, or scope it to dev-only toolsdone when…
Runtime dependencies have exactly one source of truth,
uvx deptryruns clean against it, and the three files no longer state different floors for scipy, cvxpy and scikit-learn.