[Distutils] PEP470 installation security problems

Nick Coghlan ncoghlan at gmail.com
Wed Oct 8 15:59:55 CEST 2014


On 8 Oct 2014 23:40, "M.-A. Lemburg" <mal at 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.

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.

Regards,
Nick.

>
> I'd also like to request that you take Holger's concerns more
> seriously, perhaps add him as PEP author and let him participate
> in clarifying it (if he still feels like investing time in this).
>
> PEPs are never perfect and there's always room for improvement.
>
> Thanks,
> --
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141008/b9861b82/attachment-0001.html>


More information about the Distutils-SIG mailing list