[Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

[Noah Kantrowitz]

Installing to a temp dir is really not an option for automated tooling (if nothing else, it takes way too long). `pip list --outdated` does already get fairly close to this (and doesn't install anything I suspect you can actually get a lot closer than you think) but it calculates for all packages (read: is slow) and doesn't give a good way to restrict things (hence that hack-y script which is a modified version of the pip list code). This is 100% a hard requirement for config management systems and if not fixed in pip, will require continued use of internal APIs. I would recommend just making pip list take a set of install-compatible names/version patterns and apply that as a filter in a similar way to what I've done there.

--Noah

> On Oct 20, 2017, at 11:35 AM, xoviat <xoviat at gmail.com> wrote:
> 
> There's no dry-run functionality that I know of so far. However, you could use the following:
> 
> pip install --prefix=tmpdir
> 
> This command is actually about the same speed as a proper implementation, because we can't actually know what we're installing until we build the requirements.
> 
> 2017-10-20 12:42 GMT-05:00 Noah Kantrowitz <noah at coderanger.net>:
> So as someone on the tooling side, is there any kind of install dry-run yet? I've got https://github.com/poise/poise-python/blob/master/lib/poise_python/resources/python_package.rb#L34-L78 which touches a toooon of internals. Basically I need a way to know exactly what versions `pip install` would have used in a given situation without actually changing the system. Happy for a better solution!
> 
> --Noah
> 
> > On Oct 20, 2017, at 6:22 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> >
> > We're in the process of starting to plan for a release of pip (the
> > long-awaited pip 10). We're likely still a month or two away from a
> > release, but now is the time for people to start ensuring that
> > everything works for them. One key change in the new version will be
> > that all of the internal APIs of pip will no longer be available, so
> > any code that currently calls functions in the "pip" namespace will
> > break. Calling pip's internal APIs has never been supported, and
> > always carried a risk of such breakage, so projects doing so should,
> > in theory, be prepared for such things. However, reality is not always
> > that simple, and we are aware that people will need time to deal with
> > the implications.
> >
> > Just in case it's not clear, simply finding where the internal APIs
> > have moved to and calling them under the new names is *not* what
> > people should do. We can't stop people calling the internal APIs,
> > obviously, but the idea of this change is to give people the incentive
> > to find a supported approach, not just to annoy people who are doing
> > things we don't want them to ;-)
> >
> > So please - if you're calling pip's internals in your code, take the
> > opportunity *now* to check out the in-development version of pip, and
> > ensure your project will still work when pip 10 is released.
> >
> > And many thanks to anyone else who helps by testing out the new
> > version, as well :-)
> >
> > Thanks,
> > Paul
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>