[Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

[Nick Coghlan]

On 15 April 2018 at 07:31, Donald Stufft <donald at stufft.io> wrote:
>
> On Apr 14, 2018, at 4:57 PM, Matthew Brett <matthew.brett at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia