[Distutils] PEP470 installation security problems
mal at egenix.com
Wed Oct 8 14:55:48 CEST 2014
On 08.10.2014 14:30, Nick Coghlan wrote:
> On 8 October 2014 22:22, Donald Stufft <donald at stufft.io> wrote:
>>> On Oct 8, 2014, at 8:17 AM, holger krekel <holger at merlinux.eu> wrote:
>>> Also, i am worried on principle grounds if pip maintainers are putting
>>> themselves outside PEP reach, yet pip is distributed along with Python.
>> We’re not “putting ourselves outside of PEP reach”. We are an external
>> project and we are not bound by the PEP process. Devpi, py.test, Django,
>> requests, etc are also not bound by the PEP process.
> Note also that even for CPython itself, it is *up to us as core
> developers* to decide when something needs to be escalated through the
> PEP process. The vast majority of CPython changes are handled directly
> through the issue tracker, and there's still the occasional change
> that doesn't even make it that far (e.g. if we notice a problem while
> working on something else, we have the option of just committing the
> fix directly).
> PEPs are primarily for changes which have broad ecosystem implications
> where the additional overhead is justified. We don't write PEPs for
> every change to the CPython command line interface (e.g. there's no
> PEP for isolated mode), and the same kind of assessment of external
> impact applies to pip and the PyPA in general when decided whether a
> change can be handled within the scope of an individual project, or if
> it needs to be escalated for broader discussion.
I don't follow Donald's reasoning and I'm not sure I understand
whether your comments are meant as clarification of pip being
subject to the PEP process or support for Donald's reasoning :-)
Changes to pip and PyPI *do* have a global effect on the Python
ecosystem and thus need to be covered by the PEP process.
If pip decides to go with a strategy that ignores this, I think we
have a problem. The core developers put trust into pip when allowing
it to (effectively) get distributed with Python and making it the
default Python packaging manager. Please use that trust with the
appropriate care and respect.
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
More information about the Distutils-SIG