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

[Donald Stufft]

I do think pip is pretty conservative about backwards compat other than the security related changes I've been doing. 

I think we can find the middle ground that lets things work smoothly here :). I was just making sure that we wernt going to have to keep things around for really long times like python 4 ;)

On Jul 14, 2013, at 3:35 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 14 July 2013 17:13, Donald Stufft <donald at stufft.io> wrote:
>> I think it would be reasonable for the pip maintainers to be asked to declare a public API (even if that's "None") using the naming scheme or an import warning and declare a backwards compatibility policy for pip itself so that people can know what to expect from pip. I do not however, believe it is reasonable to bind pip to the same policy that CPython uses nor the same schedule. (If you weren't suggesting that I apologize).
> 
> The main elements of CPython's backwards compatibility policy that I consider relevant are:
> 
> * Use leading underscores to denote private APIs with no backwards compatibility guarantees
> * Be conservative with deprecating public APIs that aren't fundamentally broken
> * Use DeprecationWarning to give at least one (pip) release notice of an upcoming backwards incompatible change
> 
> We *are* sometimes quite aggressive with deprecation and removal even in the standard library - we removed contextlib.nested from Python 3.2 as a problematic bug magnet well before I came up with the contextlib.ExitStack API as a less error prone replacement in Python 3.3. It's only when it comes to core syntax and builtin behaviour that we're likely to hit issues that simply don't have a sensible deprecation strategy, so we decide we have to live with them indefinitely.
> 
> That said, I think the answer to this discussion also affects the answer to whether or not CPython maintenance releases should update to newer versions of pip: if pip chooses to adopt a faster deprecation cycle than CPython, then our maintenance releases shouldn't bundle updated versions. Instead, they should follow the policy:
> 
> * if this is a new major release, or the first maintenance release to bundle pip, bundle the latest available version of pip
> * otherwise, bundle the same version of pip as the previous release
> 
> This would mean we'd be asking the pip team to help out by providing security releases for the bundled version, so we can get that without breaking the public API that's available by default.
> 
> On the other hand, if the pip team are willing to use long deprecation cycles then we can just bundle the updated versions and not worry about security releases (I'd prefer that, but it only works if the pip team are willing to put up with keeping old APIs around for a couple of years before killing them off once the affected CPython branches go into security fix only mode).
> 
> 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/ffbe6d8f/attachment-0001.html>