Package index should list dependencies and dependents
Opened this issue · 6 comments
When reading about a package, it's useful to see a list of its dependencies. This is an important description of the package, and indispensably helpful for discovering related software (particularly if dependents are listed too). Sadly PyPI doesn't show any of this information, eg. https://pypi.python.org/pypi/Flask/
For comparison, RubyGems lists dependencies, eg. https://rubygems.org/gems/rails
Runtime Dependencies
*actionmailer = 4.1.4
*actionpack = 4.1.4
While Npm lists both dependencies and dependents, eg. https://www.npmjs.org/package/trumpet
Dependencies (6) html-select, html-tokenize, through2, duplexer2, inherits, readable-stream
Dependents (35) blunt-weave, papermonk-downloader-plosone, code-music-studio, harmon, omlet, script-injector, html-prefixer, compoxure, recaster, tabby, testling-server, hammerdown, cortex-html-sauce, express-webapp-host, hyperstream, daisy-streamify, svgify, gulp-prefix, hyperglue, gparser, and 15 more
PyPI doesn't currently expose this information because it hasn't actually
got a clue what the dependencies are.
Changing that is blocked by having declarative dependency metadata or a
build farm available. Allowing publication of proper dependency info is
indeed one of the key goals for metadata 2.0.
Techincally PyPI does support it and does display it, just very few packages are uploaded in a way that tells PyPI what it's dependencies are. See: https://pypi.python.org/pypi/twine
Ah, true, I always forget about that part of metadata 1.2. Perhaps Jason
would accept a patch to add at least that much metadata 1.2 support to
setuptools?
The problem with adding it to setuptools is it won't work correctly in the fairly common case where someone conditonally adds something to install_requires. Twine does it for wheels because it has conditional dependency support.
Thanks, @hickford.
If I understand correctly, this is tracked in pypi/warehouse#789.
Based on pypi/warehouse#474 , in order to make dependency tracking work for future releases, we'd need to
- get more packagers to upgrade their toolchain to PEP 566-compliant versions
- get more packagers to upload wheels
And some of this could be via public service announcement-type campaigns, and some of it could be through policy enforced at the PyPI level (e.g., on such-and-such a date, we will stop accepting releases whose metadata versions are under 2.1).
Another option is to depend more on Libraries.io, which has and is improving its PyPI dependency tracking -- see librariesio/libraries.io#1916 and librariesio/bibliothecary#415 .