I’m wondering, why is it needed to specify both a version and a link? I assume the version specifier would be redundant when a link is provided as the source, since the link can only point to one possible package version. -- Tzu-ping Chung (@uranusjr) uranusjr@gmail.com Sent from my iPhone
On 29 Jan 2019, at 17:07, Paul Moore
wrote: On Tue, 29 Jan 2019 at 08:50, Jan Musílek
wrote: Nathaniel Smith wrote:
What would this do? I don't think there's any way for pip (or any program) to look at a git repo and extract a list of which revisions correspond to which python package versions. I guess you could have some hack where you guess that certain tag strings correspond to certain versions, but it seems pretty messy to me...
Well, I'd like it to do the exact same think as dependency_links did before they were removed from pip. AFAIK it was possible to specify `package >= 10.0` in `install_requires` and then `https://github.com/owner/package.git#egg=package-0` in `depencency_links`. I don't really see into the pip internals, so I'm not sure how pip did it in the past. But it's a real issue [1].
If this is to be an extension to the current PEP, then *someone* is going to need to specify the semantics precisely. That's part of the problem - existing behaviours are implementation defined, and not specified clearly anywhere. The first step in working out a PEP update is to define those semantics so they can be discussed without vague statements like "needs to work like dependency_links does".
I don't know how dependency_links worked, but URL links as defined in PEP 508 give "the URL to a specific artifact to install". So they link to one precise file, i.e. one precise version. So the only plausible semantics I can see for something like "package >= 10.0 @ https://github.com/owner/package.git" would be "Get the package at that URL. If it doesn't satisfy the version restriction "package >= 10.0", discard it. If it does satisfy that restriction, install it. Which doesn't seem that useful, IMO.
Maybe the way to define useful semantics here would be to articulate the actual problem you're trying to solve (*without* referring to how dependency_links works) and propose a semantics that solves that problem?
Paul -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@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/B7MZO...