<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 13, 2013, at 10:20 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 July 2013 00:54, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">This issue has been skirted round for some time now, and I think it needs explicit discussion, as I am not at all sure everyone has the same expectations.<div><br></div><div>We're talking about Python 3.4 installations having pip as the default package manager - whether by bundling, having a bootstrap process or whatever. Regardless of the means, pip will be *the* installer for Python 3.4+. And yet, I don't think pip 1.4 currently does what people want "the Python 3.4 pip" to do in some ways - and we need to make sure that any work on the pip side is understood, agreed to, and planned to match the Python 3.4 timescales.</div>
</div></blockquote><div><br></div><div>Good point. We also need to start to articulate the relevant questions for the core development side of the fence - Richard, it would be good if PEP 439 could be the vehicle for this, even though it does mean I'm shifting the goal posts on you fairly substantially.<br>
<br></div><div>Then we can turn it into a set of tracker issues for pip and CPython. As a reminder, here's the current deadlines as per PEP 429 (the 3.4 release schedule):<br><br></div><div>Changes to CPython: November 23, 2013 (3.4 beta 1)<br>
</div><div>Changes to pip: January 18, 2014 (3.4 rc 1)<br></div></div></div></div></blockquote><div><br></div><div>Good dates to have!</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>(allowing changes to bundled applications up until the first RC is what I think we *should* do, but that will require agreement from Larry Hastings as release manager)<br>
</div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div></div><div>So, here's my initial list of things that I think people might be expecting to happen. This is just my impressions, and I don't necessarily have a view on the individual items. And if anyone else can think of other things to add to the list, please do so!</div>

<div><br></div><div>1. Install to user-packages by default.</div></div></blockquote><div><br></div><div>I made this suggestion at one point, but Marcus and others convinced me it was a bad idea. Issue for better error message filed as <a href="https://github.com/pypa/pip/issues/1048">https://github.com/pypa/pip/issues/1048</a> (I don't have the power to set milestones)<br></div></div></div></div></blockquote><div><br></div><div>Added this to the 1.5 milestone and mentioned my agreement to the implementation on the ticket.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2. Not depend on setuptools (??? - Nick's "inversion" idea)</div>
</div></blockquote><div><br></div><div>I think Donald is right that bundling a vendor'ed copy of setuptools is the most sensible near-term option - there's too much risk of upgrade/downgrade issues when allowing arbitrary combinations of pip with setuptools on target systems for source based installs.<br></div></div></div></div></blockquote><div><br></div><div><a href="https://github.com/pypa/pip/issues/1049">https://github.com/pypa/pip/issues/1049</a></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>3. Possibly change the wrapper command name from pip to pip3 on Unix.</div>
</div></blockquote><div><br></div><div>I think there's a bit more to it than that. Really, what we want to try to ensure is that the following commands are available across Windows, Mac OS X and *nix (ignoring, for the moment, the behaviour of vendor provided installations for Mac OS X and Linux):<br>
<br></div><div>* python, python3, python3.4<br></div><div>* pip, pip3, pip3.4<br><br></div><div>That is, the version qualifier on the pip executable would relate to the *default Python version* associated with that executable/script, rather than the version of pip. We would take whatever steps were needed in our Windows and Mac OS X installers to ensure all these wrappers were provided.<br></div></div></div></div></blockquote><div><br></div><div><a href="https://github.com/pypa/pip/issues/1050">https://github.com/pypa/pip/issues/1050</a></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<br></div><div>The reason why I think we still want to offer "python -m getpip" is because I think that sends a clearer message to repackagers that we *do* consider pip a part of Python now, but we keep the source control and issue management for the two projects separate for pragmatic reasons (notably, the different update lifecycles). It's still going to map to two separate source tarballs (and hence SRPMs) for <br></div></div></div></div></blockquote><div><br></div><div>I don't care if getpip is available especially if that's the command that is actually executed to pre-install pip for the CPython releases. (To be clear,  I agree with Noah that pip should be pre-installed for every type of official release Python makes. However It does not need to be there from a <a href="http://hg.python.org">hg.python.org</a> checkout).</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div><br></div><div>While I acknowledge you *can* invoke the Python launcher directly on Windows, I think it is better to leave that in the background as a tool for advanced users, as well the engine that lets us base shebang line processing on Windows file associations. If/when we start offering a "py" style launcher on POSIX systems as well, then we can revisit that question.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div>4. Ensure that pip upgrading itself in-place is sufficiently robust and reliable that users don't get "stuck" on the Python-supplied version.</div></div></blockquote><div><br></div><div>As Vinay noted, we also need to ensure downgrades work. However, must of these have been related to depending on an external setuptools, so eliminating that should help a lot.<br></div></div></div></div></blockquote><div><br></div><div>In the years of using pip the only time i've ever had any issue upgrading or downgrading pip was related to setuptools screw ups. But possibly we do want to have some explicit testing around this?</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>I'm sure I've seen people say other things that have made me think "are you expecting the pip maintainers to make that change?" in the various threads, so I doubt this list is definitive.</div>
</div></blockquote><div><br></div><div>The other big one is the one you noted about pip *not* offering a stable API, *but* exposing an apparently stable API to introspection. Introspection currently tells me that pip exports *at least* 32 public names (and this is without checking for public submodules that aren't implicitly imported by pip/__init__.py):<br>
<br>>>> import pip; public = set(k for k, v in pip.__dict__.items() if not k.startswith('_') and (not hasattr(v, "__name__") or hasattr(v, "__module__") or v.__name__.startswith("pip."))); print(len(public))<br>
32<br><br></div><div>If pip really has no stable public API, then it should properly indicate this under introspection (if it already uses relative imports correctly, then the easiest ways to achieve that are to just shove everything under a "pip._impl" subpackage or shuffle it sideways into a "_pip" package).<br></div></div></div></div></blockquote><div><br></div><div>Pip does not use relative imports. Is simply documenting the fact there is no public API enough? Pushing everything into a _impl or _pip directory makes me nervous because that's a lot of code churn (and I know there are people using those APIs, and while they aren't technically stable it feels like moving things around just for the sake of an _ in the name is unfriendly to those people.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div></div><div>Comments anyone? Is this discussion premature? The pip maintainers team is not huge, so we'll need time (or assistance!) to plan in and make changes like this, if they are needed...</div></div></blockquote>
<div><br></div>Agreed, I think refocusing the discussion on "What do we need to do in pip?" and "What do we need to do in CPython?" is a very necessary step at this point.<br></div></div></div></blockquote><div><br></div><div>Agreed.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div></div><div>At a minimum, can we get the key items logged on the pip issue tracker with a milestone of Python 3.4?</div></div></blockquote><div><br></div><div>The existing 1.5 milestone is probably usable - I expect 1.5 is the version that would be bundled with 3.4.<br></div></div></div></div></blockquote><div><br></div><div>Instead of a milestone I added a PEP439 tag so that we can differentiate between 1.5 milestone items for PEP439 and not. Ideally we don't need to drop anything from 1.5 but just in case we do.</div><div><br></div><div>I think we should probably target pip 1.5 to release in the beginning of December? Would need to see what the other team members think, that's a shorter release cycle then we normally have but I think it'd be good to have 1.5 out for a month or so to get real world use to make sure it doesn't need a patch release before inclusion in CPython (assuming the dates you mentioned are correct).</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<br></div><div>Cheers,<br></div><div>Nick.<br></div><div><br></div></div>-- <br>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia
</div></div>
_______________________________________________<br>Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br><a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a><br></blockquote></div><br><div>
<br>-----------------<br>Donald Stufft<br>PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

</div>
<br></body></html>