On 08.10.2014 15:59, Nick Coghlan wrote: > On 8 Oct 2014 23:40, "M.-A. Lemburg" <m...@egenix.com> wrote: >> The intention of PEP 435 was to enable pip to evolve independent >> of the Python release process, which is a good thing. >> >> However, your comment that "We are an external project and we are not >> bound by the PEP process." doesn't really pan out in the light of the PEP's >> requirement that "The maintainers of the bootstrapped software and the >> CPython core team will work together in order to address the needs of >> both." >> >> If pip maintainers don't feel they are bound by PEPs, you could argue >> that you are also not bound by PEP 435, which would result in a >> rather pointless cooperation setup :-) >> >> Note that I'm not trying to say that you are actually not respecting the >> PEP process. I'm just concerned about comments like the above causing >> unnecessary heat in discussions. > > pip's UX decisions aren't likely to ever be put through the PEP process > again - the PEP 426 (and now PEP 470) model of providing functional > requirements and recommendations in the form of MUST and SHOULD statements > is a cleaner process, since they provide guidance for all clients, not just > pip, and leave the *details* of the UX to the normal pip development cycle > (so if user feedback indicates a problem with the specifics of the initial > approach, they can address that while remaining compliant with the > specification). > > Decoupling functional specifications from UX details of individual tools is > a good idea in general, this is just applying that model to pip and the PEP > process in particular.
IMO, specific user interface questions are PEP relevant if they affect the way users interact with the Python ecosystem. This doesn't mean mandating specific option names, but e.g. --using-silly-long-options-that-scare-away-users does have PEP relevance. A PEP would have to address such user interface designs by defining whether or not to encourage or discourage certain uses. And, of course, pip as officially sanctioned Python installer would need to implement these requirements. > PyPI needs to be covered in more detail, however, as these PEPs also serve > as the *interface* specification for both clients and servers, and those > need concrete API definitions to work with. > > PEP 438 was the main case so far where the PEP included specific UX design > details for pip, and that's the aspect that *won't* be repeated. PEPs are not set in stone. They can be updated and replaced with new ones. That's why they are called "Python Enhancement *Proposals*" :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
