On Tue, 29 Jan 2019 at 15:07, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > 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).
Precisely. > 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? Again, precisely. Pip already has mechanisms (find-links and extra index URL) to do this at the top level, and letting projects do it in their config is basically a remote code exploit (admittedly install from source is already that). > 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. Someone could make a front-end application that, given a github URL, presented the content of that repository as a PEP 503 index. That's pretty much the purpose of standardising the repository API in a PEP. And that application could include as much configurability and intelligence as its users desired. It would also work identically in any standards-conforming installer. Paul -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/IKSEBWBWGIF6EOIBODVYXISA6T7TFBBJ/
