Re: Update PEP 508 to allow version specifiers

> On Jan 29, 2019, at 9:02 AM, Xavier Fernandez <[email protected]> wrote:
> 
> Thanks Jan for raising this issue.
> 
> On Tue, Jan 29, 2019 at 10:21 AM Tzu-ping Chung <[email protected] <mailto:[email protected]>> 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/archives/list/[email protected]/message/US7A64MUFODAF2LKDNVBWIR5D4MZTFJF/