[Distutils] Any interest in Perforce support in pip?

[Paul Moore]

On 29 January 2018 at 04:45, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 29 January 2018 at 11:54, Robert Collins <robertc at robertcollins.net> wrote:
>> It won't be testable by most developers, if be inclined to say that making
>> the VCS layer a supported plugin point would be a better patch to merge.
>> That would be testable.
>
> Right, I suspect without that, the Perforce support would end up
> intermittently broken, since pre-merge CI wouldn't be able to cover
> it.

The existing PR does actually include tests that install and verify
Perforce functionality. I don't follow all the details, but the intent
is definitely there - Barney has done a good job with the PR.

> By contrast, if there was a patch that managed a registry of VCS
> scheme handlers, and the existing scheme handlers (git, Mercurial,
> bzr, svn) were migrated to that, then:
>
> - pip's own pre-merge CI would ensure that the plugin API itself always worked
> - a separate "pip-vcs-p4" project could require Perforce availability
> to run their CI

The worst problem here is that without a supported pip API, pip-vcs-p4
has to rely on APIs that could potentially change at short notice,
making plugin versioning a non-trivial problem to solve. I'm
personally fine with plugins relying on internal APIs (on a "you deal
with the risks" basis) but we'd need to give plugins a way to say "I
only work with versions X, Y and Z of pip, as an API I use changed".
Maybe existing dependency methods can handle this, but I've not
thought that through fully.

> As a sketch of a way that could work, pip could define a new "pip.vcs"
> entry point group, where the keys were scheme names, and the values
> were object references pointing to handlers for those schemes.

If that could work (see the comments about coupling to pip versions I
mentioned above) then I think that it would be a reasonable option.
Usual caveat - it's easy to discuss ideas like this, but much harder
to find anyone to work them through to completion. There's been at
least one previous iteration of this idea (the only one I can find at
the moment is https://github.com/pypa/pip/pull/4146, but that seems
focused on the pip API issue, and I think there were others that
covered other aspects of the problem, but my github-foo is failing me
right now).

Paul

PS Although I'm accepting the idea of 3rd party VCS plugins working
with pip's internal APIs above, I'm saying this purely on the basis of
looking for a practical way out of the current problem, where we don't
want to bring code to handle reasonable use cases into pip core, but
we don't offer any way for interested parties to maintain it outside
of pip. I fully expect "you changed this internal API" and "VCS
plugins use it why can't we?" issues to make us regret this decision
if we make it...