Expose pip.main (but it's still unsupported)

[pfmoore]

No description provided.

[pfmoore]

Not sure if we want to do this. It remains an unsupported API, but virtualenv uses it so this is a low-cost fix to avoid breaking virtualenv (and to avoid virtualenv visibly using pip's _internal namespace...)

[dstufft]

I don't think we should expose this. The entire point of the move to _internal was to make it obvious that all of these APIs are unsupported because it was confusing that pip.foo looked like a public API but wasn't.

The only reason to do this is because a few tools in our control need to call this and can't call a subprocess. These tools are virtualenv, get-pip.py, and ensurepip. However get-pip.py and ensurepip are explicitly locked to a specific version specifically to prevent breakages from changes in pip's internal API. Virtualenv doesn't lock to a specific version for historical reasons, but we've also regularly broken support for old versions of pip in virtualenv bootstrapping so that's nothing new for us.

In any case, we're still going to have to reach into a private directory (and we do this today!) because we have to reach into pip/_vendor to extract the certificate bundle. This mess with virtualenv/get-pip.py/ensurepip essentially flows from the fact that we're trying to use pip to install pip, so there doesn't yet exist a command to subprocess-- this is effectively a use case that is entirely unsupported unless you're one of us.

[pfmoore]

OK, cool. Those arguments are enough for me (although I suspect that fixing virtualenv so that it works with older versions of pip will be fiddly - but I'll leave that for whoever wants to raise the PR to fix virtualenv).

BTW, do we have any feel at all for whether any widely-used packages will break when pip 10 gets released? I did a quick scan of what I have locally, and pipsi and pew seem OK. pipenv will break horribly, but not because of pip.main - they use a lot of internal pip APIs :-( I wonder if we should warn them...?

[pradyunsg]

BTW, do we have any feel at all for whether any widely-used packages will break when pip 10 gets released?

I think the announcement on distutils-sig is a big enough audience? Given that there's over 2 months, it should be fine?

[pfmoore]

I'll send an email to distutils-sig pointing out that anyone relying on pip internals has work to do and we're starting planning on a new release (without committing to a time at this point, there's enough coming out of the woodwork that I want to let things settle before doing that).

[pradyunsg]

Sounds perfect to me. :)

[pfmoore]

OK, I've lit the blue touchpaper by sending the email to distutils-sig and pypa-dev. I may well now go AWOL over the weekend till the screams die down 😟 🙉

[benoit-pierre]

I think this should be re-considered: do you really want to have to field "updating pip broke my launcher" bugs until (at least) 2023?

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.