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