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

[xoviat]

The "installing collected packages" output is not always correct. The
"successfully installed [package list]" is always correct
(see pypa/pip/issues/4724 for an example).

I understand your requirements, but is the practical implication that pip
should offer a command that outputs packages that are potentially
incorrect? What happens when someone relies on that and then files a bug
report?

2017-10-20 13:48 GMT-05:00 Noah Kantrowitz <noah at coderanger.net>:

> While I understand that pip itself has to be very careful about edge cases
> and all the pathological things you can do in setup.py, as a higher-level
> tooling author my priorities are on the happy path UX and speed is a big
> factor there. So yes, using PackageFinder is potentially inaccurate, but
> it's also _usually_ accurate :) Anyways, if there is true concern that
> finder-based approaches are too risky, probably don't offer it in the pip
> list output.
>
> --Noah
>
> > On Oct 20, 2017, at 11:43 AM, xoviat <xoviat at gmail.com> wrote:
> >
> > A correct dry-run implementation will do about the same amount of work
> as installing to a temporary directory right now. In the future, that could
> be optimized, but any patch to the finder doesn't actually detect the
> requirements correctly (as they're not necessarily known until after the
> wheels are built).
> >
> > 2017-10-20 13:41 GMT-05:00 Noah Kantrowitz <noah at coderanger.net>:
> > 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
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171020/d77bca29/attachment.html>