6813
Comment: pip UX
|
8377
quoting Nick Coghlan when adding package metadata audit
|
Deletions are marked like this. | Additions are marked like this. |
Line 27: | Line 27: |
* [[https://github.com/pypa/packaging-problems/issues/54|listing packages' dependencies and depdendents on PyPI]] | |
Line 28: | Line 29: |
* [[https://github.com/pypa/pipenv/issues?q=is%3Aopen+is%3Aissue+label%3A%22Category%3A+Dependency+Resolution%22|better pipenv functionality]] | |
Line 71: | Line 73: |
Pip's user experience needs to become more consistent across features, fit the user's mental model better, reduce unintended data loss, and provide [[https://github.com/pypa/pip/milestone/25|better error messages]] and prompts, logs, output, and reporting. Pip's maintainers have [[https://github.com/pypa/pip/milestone/10|a list of TODOs]] and need funding so that user experience researchers, UX designers, developers, and technical writers can spend dedicated time addressing them. | pip's user experience needs to become more consistent across features, fit the user's mental model better, reduce unintended data loss, and provide [[https://github.com/pypa/pip/milestone/25|better error messages]] and prompts, logs, output, and reporting. pip's maintainers have [[https://github.com/pypa/pip/milestone/10|a list of TODOs]] and need funding so that user experience researchers, UX designers, developers, and technical writers can spend dedicated time addressing them. === Security notifications for vulnerable packages === To keep PyPI's users secure, we want to give them [[https://github.com/pypa/warehouse/issues/798|an opt-in communication channel to hear about security vulnerabilities for the packages they use]]. Implementing this would also give us architectural support to ''warn or prevent'' pip users who try to install a PyPI package that's been found to be broken or malware. We need funding for user experience work, development, testing, infrastructure, potentially platform services (e.g., SMS), and community outreach. |
Line 76: | Line 82: |
=== Audit and update package metadata === If we [[https://github.com/pypa/warehouse/issues/474#issuecomment-370986838|audit and update PyPI metadata for existing projects based on already-uploaded artifacts]], we can publish information about what packages depend on each other and on certain environments, and ensure a high-quality API for many tools to reuse and build upon. The current PyPI upload API relies on the upload client extracting the metadata and supplying it with the first upload request, and that isn't a valid assumption for older upload clients. Currently, our constraint is a combination of developer time, compute resources, and privileged backend database access; funding would break this bottleneck. |
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
We're partway through a next-generation rewrite of the dependency resolver within pip, Python's package download and installation tool. The project ran into massive technical debt, but the refactoring is nearly finished and prototype functionality is in alpha now. (In-depth explanation by Sebastian Awwad of the problem & our approach, lead developer Pradyun Gedam's initial plan and 2017 status updates, GitHub issue #988 tracking progress and issue #6536 for planning rollout.)
Funding would support user experience, communications/publicity, and testing work (including developing robust testing/CI infrastructure) as well as core feature development and review.
We need to finish the resolver 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
moving more code out of Python's standard library so we can release improvements faster
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. This will help us get faster at testing and rolling out bugfixes and features for all Python packaging and distribution tools: well-known projects like pip, virtualenv, and wheel, but also all the downstream projects that depend on them.
System to label projects on PyPI with administrative statuses/attributes
To scale up our anti-abuse moderation and help package maintainers with security response, we need to be able to, for instance, mark a release as deprecated or a project as unsupported. This means we need a generic system to add, edit, and remove administrative attributes ("flags" or "statuses") to individual projects and releases. We need support to do the architectural design to implement this. (See notes from this meeting.)
Feature flag system on PyPI
It's difficult to roll out new features gradually to PyPI's test site or to selected test users. A feature flag system would help us do targeted outreach to particular groups of users, deploy more confidently, and roll back changes when needed.
Improve pip user experience
pip's user experience needs to become more consistent across features, fit the user's mental model better, reduce unintended data loss, and provide better error messages and prompts, logs, output, and reporting. pip's maintainers have a list of TODOs and need funding so that user experience researchers, UX designers, developers, and technical writers can spend dedicated time addressing them.
Security notifications for vulnerable packages
To keep PyPI's users secure, we want to give them an opt-in communication channel to hear about security vulnerabilities for the packages they use. Implementing this would also give us architectural support to warn or prevent pip users who try to install a PyPI package that's been found to be broken or malware. We need funding for user experience work, development, testing, infrastructure, potentially platform services (e.g., SMS), and community outreach.
Rewrite virtualenv
Audit and update package metadata
If we audit and update PyPI metadata for existing projects based on already-uploaded artifacts, we can publish information about what packages depend on each other and on certain environments, and ensure a high-quality API for many tools to reuse and build upon. The current PyPI upload API relies on the upload client extracting the metadata and supplying it with the first upload request, and that isn't a valid assumption for older upload clients. Currently, our constraint is a combination of developer time, compute resources, and privileged backend database access; funding would break this bottleneck.