> On Jan 29, 2019, at 9:02 AM, Xavier Fernandez <xav.fernan...@gmail.com> wrote:
> 
> Thanks Jan for raising this issue.
> 
> On Tue, Jan 29, 2019 at 10:21 AM Tzu-ping Chung <uranu...@gmail.com 
> <mailto:uranu...@gmail.com>> wrote:
> 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.
> 
> The same could be said from the package name: when a link is provided, the 
> name is redundant since the link can only point to one possible package name.
> 
> If a version specifier was allowed for direct references, this would the same 
> thing: it would be the installer job to check that the provided link matches 
> the provided version specifier, just like it should be checking that the 
> package name matches ;).
> If the direct references was inconsistent, the installer could print a 
> warning or abort the installation.

I don’t think that’s accurate, it’s not really the redundancy that’s the issue 
here (although it is silly).

Conceptually a dependency declaration is 2 things, the name of the dependency, 
and a range of acceptable versions.

In the old, dependency_links days you declared your dependency as normal (foo 
>= 1.0), but if that didn’t exist on PyPI (or wherever your installer was 
configured to look at), you could add a dependency link that acted as a hint to 
some other locations that this dependency might exist at. Thus having “3” 
pieces of the puzzle made sense here, you had the name and version specifier 
that indicated what dependencies you were looking for, and the dependency links 
that hinted where they might be found.

In the new PEP 508 style, we’ve removed dependency links, and allowed you to 
say that the only acceptable version is the one located at some specific URL. 
Thus the URL itself is the version specifier, because conceptually, the only 
legal version is the one referred to at that URL. It still declares a name in 
the specifier because when doing the dependency resolution algorithm, it needs 
to know the name and the version, and conceptually the name and version of “foo 
@ https://example.com/foo.tar.gz <https://example.com/foo.tar.gz>” is (“foo”, 
“https://example.com/foo.tar.gz <https://example.com/foo.tar.gz>”).

The two features are basically not 1:1, given that PEP 508 url specifier short 
circuits the URL discovery phase completely, whereas dependency_links only 
provide hints for additional places to look. Trying to cram version specifiers 
into the PEP 508 style syntax is not going to work as people expect, because it 
is conceptually nonsensical.

However, one thing we *could* maybe do is allow including a specific version. 
So instead of treating the URL as the version you would provide the name, 
version, and url. So you’d have something like "foo-1.0 @ 
https://example.com/foo.tar.gz <https://example.com/foo.tar.gz>”. I don’t 
personally see much of a point to that, the version number doesn’t tell us any 
new information here, the only thing I think it *could* be useful for, is if 
you had something depending on “foo >= 1” and something else depending on 
“foo-1.0 @ …” then it would make it easier to determine there isn’t a 
dependency conflict.
--
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/US7A64MUFODAF2LKDNVBWIR5D4MZTFJF/

Reply via email to