On 15 April 2018 at 07:31, Donald Stufft <don...@stufft.io> wrote: > > On Apr 14, 2018, at 4:57 PM, Matthew Brett <matthew.br...@gmail.com> wrote: > > 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]. > > The best solution is to figure out what APIs people need, and either add > them to packaging and have pip consume that as well as anyone else, or make > a new library for the same. > > If that’s unacceptable, vendoring or version pinning is probably the best > option.
I think there are going to be at least two steps involved for most projects affected by the API change: 1. The quick fix to add pip 10 compatibility (which is likely a matter of "copy the code you need into the project that needs it") 2. The technical debt reduction to reduce code duplication (which is likely a matter of "add the required APIs to the 'packaging' project") Step 2 is the step that the pip internals refactoring is designed to encourage, as we believe a lot of tool developers were just using pip's internal APIs rather than filing RFEs and submitting PRs to help guide the evolution of the stable APIs in packaging in a use-case driven manner. FWIW, `pipenv`'s currently still on "Step 1" at the moment (and has a lot of internal refactoring of its own ahead of it before it will really move on to step 2). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia