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 <xov...@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 <n...@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.mo...@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@python.org > > https://mail.python.org/mailman/listinfo/distutils-sig > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig