On 29 January 2018 at 04:45, Nick Coghlan <ncogh...@gmail.com> wrote: > On 29 January 2018 at 11:54, Robert Collins <robe...@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... _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
