|
Size: 3287
Comment: pip resolver blockers
|
Size: 4216
Comment: more pip dependencies
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| We need to finish this because so many other improvements are blocked on it, such as: | We need to finish this because so many other improvements are blocked on it: |
| Line 20: | Line 20: |
| * [[https://github.com/pypa/packaging-problems/issues/264|making PyPI and pip enforce metadata compliance more strictly]] | |
| Line 21: | Line 22: |
| * [[https://github.com/pypa/pip/issues/6495|properly respecting constraints]] * [[https://github.com/pypa/pip/issues/53|option to show what versions of packages are currently available]] |
|
| Line 22: | Line 25: |
| and it would fix so many dependency issues for our users, such as: | and it would fix so many dependency issues for our users: |
| Line 28: | Line 31: |
| * [[https://github.com/pypa/pip/issues/4957|extras installation failure]] * [[https://github.com/pypa/pip/issues/4391|extras upgrade failure]] * [[https://github.com/pypa/pip/issues/6494|breaking installed packages]] * [[https://github.com/pradyunsg/zazo/issues/14|elasticsearch/requests failure]] |
|
| Line 29: | Line 36: |
| And in our larger ecology, this causes installation problems -- for example: | And in our larger ecology, this causes installation problems for: * [[https://github.com/conda/conda/issues/8657|conda's compatibility with pip]] * [[https://github.com/servo/servo/issues/10611|the Servo browser engine]] * [[https://github.com/juju/python-libjuju/issues/45|Canonical's DevOps tool Juju]] |
| Line 37: | Line 47: |
| * [[https://github.com/gerkey/ros1_external_use/issues/7|Robot Operating System tooling]] |
Packaging improvements that could be funded
This page lists specific things that
- the Python packaging community wants
- are fairly well-scoped
- would happen much faster if the Packaging Working Group got funding to achieve them
Projects
finish dependency resolver for pip
See pip issue #988 and #6536. This includes help with user experience, communications/publicity, and testing (including developing robust testing/CI infrastructure) as well as, potentially, core feature development and review.
We need to finish this because so many other improvements are blocked on it:
warning when trying to download or build wheels from incompatible set of packages/requirements
making PyPI and pip enforce metadata compliance more strictly
warning the user when uninstalling a package that other packages depend on
option to show what versions of packages are currently available
and it would fix so many dependency issues for our users:
And in our larger ecology, this causes installation problems for:
Robust interoperability testing
We need funding to ensure core packaging tools work well with each other; currently they aren't seamlessly interoperable. See the integration-test project.
System for generic statuses/flags on projects on PyPI
See notes from this meeting. To scale up our anti-abuse moderation, we need to be able to, for instance, mark a release as deprecated or a project as unsupported. We need support to do the architectural design to implement this.
Feature flag system on PyPI
It's difficult to roll out new features gradually to our test site or to selected test users; a feature flag system would help us deploy more confidently. See this GitHub issue.