On Tue, Jan 29, 2019, at 2:43 PM, Paul Moore wrote:
And when they start adding version numbers to that (like the OP's package >= 10.0 @ https://github.com/owner/package.git) I can't even begin to understand what they think it might mean.
I presume the idea is that it uses that repository like an extra index for that specific package, as if you had done: pip install --find-links https://github.com/owner/package.git package That doesn't work because pip doesn't have the machinery to identify Python package releases in a GitHub repository, but it's not hard to imagine how it could work if you assume tags follow a standard pattern (I'm not saying it should do that). If I've understood this correctly, the idea can be broken down into two parts: 1. Should it be possible to specify an extra index URL for a specific package? If a package itself can specify an index URL for its dependencies, you're back to the problems of crawling random sites. If this is only usable at the top level of packages you're asking pip to install, it's probably of limited use. And there are obvious complications: do you use the same index for dependencies of that package? What about if it shares dependencies with other top-level packages? 2. Should tools like pip be able to find a list of releases in a git (or specifically GitHub) repository? I think this would be too complicated to make a good standard - how do you distinguish 'release of a Python package' tags from any other tags that might be in the repository? Someone could make an installer tool that works with git repositories like this, assuming some convention of tags and file layout. But I'd vote against pip doing that, because anything that pip implements, every other installer tool will inevitably be pushed to implement for compatibility. Thomas