Hi, On Sun, Oct 22, 2017 at 8:52 AM, Elvis Stansvik <elvis.stans...@orexplore.com> wrote: > 2017-10-21 14:34 GMT+02:00 Paul Moore <p.f.mo...@gmail.com>: >> On 21 October 2017 at 12:15, Nick Coghlan <ncogh...@gmail.com> wrote: >>> (Note: this is entirely speculative, and I have no idea how hard it would >>> be, so please read it as the question it's intended to be) >> >> No problem - I don't know myself how hard some of this would be, either ;-) >> >>> Do you know if there any key APIs (like installation) that could be turned >>> into wrappers around pip CLI calls in order to mitigate some of the impact? >> >> The obvious one is pip.main(). That's the one a lot of people use, but >> it's easily replaceable by a simple subprocess call. That's actually >> one of the reasons this was so frustrating to us - the bug reports we >> got were often from people doing things they didn't need to, that they >> could handle trivially via a supported approach. >> >> Otherwise, no. We've had little or no feedback on the tracker from >> people using more complex internals, so our working assumption has >> been there's very little that can't be handled via the CLI or existing >> packages. Feedback so far from this mail hints that maybe we were >> wrong, but it's still hard to know if it's one or two key projects, or >> a whole range of people that we've yet to hear from. I'm pretty sure, >> for example, that pipenv uses internals, either directly or via one of >> their dependencies, but we've not seen any feedback from them yet. > > Another one that immediately comes to mind is pip-tools [1], which I > think is quite widely used. > > But I just checked, and they filed a "check out how to deal with pip > 10" issue two days ago [2] (I'm guessing in response to this thread).
Now pip 10 is out, of course, I discover that I've lost the implementation of `get_supported` in pip.pep425tags. It's my fault for not remembering I had used it. Is the suggestion to use the `_internal` import, or carry a copy of the pep425tags code myself, that I have to keep up to date with the internal pip copy? That would also involve me copying the `glibc` part of the code. I see that the `wheel` package has an old copy of that code too, which doesn't deal with manylinux wheels. You probably saw that `pip-tools` ended up vendoring the whole of pip9 [1]. Cheers, Matthew [1] https://github.com/jazzband/pip-tools/tree/master/piptools/_vendored/pip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig