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 <n...@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 <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-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
