| Summary: | [TRACKER] Mis-synced deps/requires.txt | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 588676, 619330, 619334, 619336, 619338, 619340, 619342, 619344 | ||
| Bug Blocks: | |||
Dead tracker? |
Now that gpy-verify-installed-reqs has been pushed to the repo, we can verify whether the installed packages have dependencies fully satisfied. Sadly, it can not verify dependency lists in ebuilds for us but it's still a step forward ;-). Example output: $ python3.6 gpy-verify-installed-reqs {'eventlet'} MISSING enum-compat {'logilab-astng'} MISSING logilab-common>=0.53.0 {'mergedict'} MISSING singledispatch {'pylint'} VERSION CONFLICT astroid<1.5.0,>=1.4.5 astroid 1.5.2 {'pytest-cache'} MISSING execnet>=1.1.dev1 {'sure'} MISSING mock LHS is base package, RHS explains what kind of dependency issue it found. MISSING means dep is not installed at all; VERION CONFLICT means we have version outside allowed range. -- Now, why this is a problem: a unsatisfied/conflicting dependency in installed Python package can cause two undesired effects on setuptools/pkg_resources: 1. pkg_resources will refuse to run entry_points (scripts) for the package in question and *all* its reverse dependencies, 2. setuptools may attempt to fetch & install missing dependencies in some cases (e.g. when running setup.py test). Therefore, it is important that we always ensure that the dependencies can be satisfied. If you get this kind of report, this either indicates that the upstream dependencies are overstrict, or our dependencies are not appropriate. Things that need considering: 1. if our dependency is wrong and the package indeed does not work without the package (or with specific version of the package), we need to fix our dependency, 2. if upstream dependency is overstrict (i.e. enforces specific version when other versions work), we can just sed or patch the requirement to be more lax, 3. if upstream dependency is applied unconditionally but it's needed only for some implementations, we can either fix it (i.e. add platform specifier) or sed it out. Note that 'upstream dependencies' are the dependencies listed in setup.py. Upstreams frequently move them to the 'requirements.txt' file but you need to verify setup.py as well.