<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><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><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><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>
<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><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><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> <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 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>
<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>