<p dir="ltr"><br>
On 8 Oct 2014 23:40, "M.-A. Lemburg" <<a href="mailto:mal@egenix.com">mal@egenix.com</a>> wrote:</p>
<p dir="ltr">><br>
> The intention of PEP 435 was to enable pip to evolve independent<br>
> of the Python release process, which is a good thing.<br>
><br>
> However, your comment that "We are an external project and we are not<br>
> bound by the PEP process." doesn't really pan out in the light of the PEP's<br>
> requirement that "The maintainers of the bootstrapped software and the<br>
> CPython core team will work together in order to address the needs of both."<br>
><br>
> If pip maintainers don't feel they are bound by PEPs, you could argue<br>
> that you are also not bound by PEP 435, which would result in a<br>
> rather pointless cooperation setup :-)<br>
><br>
> Note that I'm not trying to say that you are actually not respecting the<br>
> PEP process. I'm just concerned about comments like the above causing<br>
> unnecessary heat in discussions.</p>
<p dir="ltr">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).</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Regards,<br>
Nick.<br></p>
<p dir="ltr">><br>
> I'd also like to request that you take Holger's concerns more<br>
> seriously, perhaps add him as PEP author and let him participate<br>
> in clarifying it (if he still feels like investing time in this).<br>
><br>
> PEPs are never perfect and there's always room for improvement.<br>
><br>
> Thanks,<br>
> --<br>
> Marc-Andre Lemburg<br>
> eGenix.com<br>
><br>
> Professional Python Services directly from the Source<br>
> >>> Python/Zope Consulting and Support ...        <a href="http://www.egenix.com/">http://www.egenix.com/</a><br>
> >>> mxODBC.Zope.Database.Adapter ...             <a href="http://zope.egenix.com/">http://zope.egenix.com/</a><br>
> >>> mxODBC, mxDateTime, mxTextTools ...        <a href="http://python.egenix.com/">http://python.egenix.com/</a><br>
> ________________________________________________________________________<br>
><br>
> ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::<br>
><br>
><br>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48<br>
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg<br>
>            Registered at Amtsgericht Duesseldorf: HRB 46611<br>
>                <a href="http://www.egenix.com/company/contact/">http://www.egenix.com/company/contact/</a><br>
</p>