[Distutils] Expectations on how pip needs to change for Python 3.4

[Nick Coghlan]

On 14 July 2013 16:34, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 14 July 2013 16:19, Noah Kantrowitz <noah at coderanger.net> wrote:
>
>> On Jul 13, 2013, at 10:58 PM, Nick Coghlan wrote:
>> > On 14 July 2013 12:46, Donald Stufft <donald at stufft.io> wrote:
>> > Either the existing APIs are moved to a different name, or they get
>> declared stable and pip switches to "internally forked" APIs any time a
>> backwards incompatible change is needed for refactoring purposes (see
>> runpy._run_module_as_main for an example of needing to do this in the
>> standard library). I've had to directly deal with too many issues arising
>> from getting this wrong in the past for me to endorse bundling of a module
>> that doesn't follow this practice with CPython - if introspection indicates
>> an API is public, then it's public and subject to all standard library
>> backwards compatibility guarantees, or else we take the pain *once* and
>> explicitly mark it private by adding a leading underscore rather than
>> leaving it in limbo (contextlib._GeneratorContextManager is a standard
>> library example of the latter approach - it used to lack the leading
>> underscore, suggesting it was a public API when it's really just an
>> implementation detail of contextlib.contextmanager).
>> >
>>
>> Respectfully, I disagree. Pip is not going in to the stdlib, and as such
>> should not be subject to the same API stability policies as the stdlib. If
>> the PyPA team wants to break the API every release, that is their call as
>> the subject matter experts. Pip is not being included as a library at all.
>> What should be subject to compat is the defined command line interface,
>> because pip is a CLI tool. Independently of this discussion I've already
>> been talking to the PyPA team about what they want to consider a stable
>> API, but that is a discussion to be had over in pip-land, not here and not
>> now. This new category of "bundled for your convenience but still external"
>> applications will need new standards, and we should be clear about them for
>> sure, but I think this is going too far and puts undue burden on the PyPA
>> team. Remember the end goal is simply to get an installer in the hands of
>> users easier.
>>
>
> I would also be fine with a solution where "import pip" issues a warning
> about API instability if sys.argv[0] indicates the main executable is
> something other than the pip CLI.
>

Oops, meant to add a point to https://github.com/pypa/pip/issues/1052 for
that one.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130714/d09222fa/attachment-0001.html>