Hi, On Sun, Oct 22, 2017 at 8:52 AM, Elvis Stansvik <elvis.stansvik@orexplore.com> wrote:
2017-10-21 14:34 GMT+02:00 Paul Moore <p.f.moore@gmail.com>:
On 21 October 2017 at 12:15, Nick Coghlan <ncoghlan@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