FWIW we are using quite a bit of the internal api. My plan was to go over this 
once we cut over to the new warehouse uris. Of note might be the fact that 
pip-tools is a core dependency we bundle in pipenv and the current maintainer 
is a pipenv maintainer as well. For our specific case we have made sizeable 
changes to the dependency resolution stack and bundling allows us to patch 

I don’t know that we are a good example though, we are doing significantly more 
with pip internals than the average project


Dan Ryan // pipenv maintainer
gh: @techalchemy

> On Apr 14, 2018, at 11:24 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> 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
Distutils-SIG maillist  -  Distutils-SIG@python.org

Reply via email to