Ned Deily added the comment: Let me just expand on my concerns here. I apologize for not thinking about these earlier: I haven't been paying enough attention to this project. And I certainly do not intend this to be a criticism of anyone's work on this, especially your work, Upendra and your mentoring, Lorenzo and Terry. Thank you! The issues I'm concerned about here are not so much technical but rather related to process and long-term maintenance.
As is discussed in PEP 453, https://www.python.org/dev/peps/pep-0453/, which describes how pip was made available through the Python Standard Library, there was a clear boundary drawn between pip development and the standard library: "This PEP does not propose making pip (or any dependencies) directly available as part of the standard library. Instead, pip will be a bundled application provided along with CPython for the convenience of Python users, but subject to its own development life cycle and able to be upgraded independently of the core interpreter and standard library." What the standard library provides are mechanisms to deliver pip in a standard library (for example, via the "ensurepip" module) but there is deliberately almost no documentation in the standard library about the use of pip. Rather there are links to the official Python Packaging Authority pip documentation. This was to ensure that pip development remains decoupled from Python development; both can operate on their own cycles and have different goals and requirements. For example, a given pip release typically supports a broad range of Python releases; pip has intimate dependencies on other resources, like PyPI, ones that Python itself doesn't (or at least as tightly coupled as pip has). Yes, it's not 100% clean but the separation of concerns and design authority was and remains a very important part of the relationship between pip and Python as independent projects. And that independence also means that the details of how users interface with pip in the current command line env ironment - what commands are available, what options each has, default values, current best practices - are the purview of the Python Packaging Authority and the pip project, not Python development. This translates directly into the whole user experience when using a gui instead of a cli. As we all know, user experience and user interface design is *hard*, especially in the multi-platform environment that Python and pip operate in and especially for relatively naive users, presumably the primary audience for such a gui. It's nice to think of having an IDLE gui interface for pip but treating it as an IDLE feature rather than a pip feature violates the intent of PEP 453 (IMO) and jeopardizes the chance for this feature being successful and has the potential to disrupt the success of PEP 453. In the spirit of PEP 453, I think the gui interface (or at least the bulk of it) needs to be design-reviewed and approved by the Python Packaging Authority and somehow be part of the pip development and release process. Python releases would deliver it initially via the current ensurepip and third-party packager mechanisms and the gui would be updated through normal pip mechanisms, asynchr onously of Python releases, so that the gui remains synchronized with pip. Ideally, the gui would be not dependent on IDLE at all; IDLE would just provide convenience UI elements to launch the gui. Perhaps this has been discussed before and included in the project plans. If not, I think it needs to be now before we commit ourselves to creating a new set of potentially problematic dependencies for the future. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27051> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
