> but I guess it could be interpreted as “you can find the package here, and I promise it satisfies the given specifiers

Promising to satisfy a vague constraint isn’t very useful though, is it? Since it’s not providing a strict pin you aren’t even getting enough information to leverage the local cache until you actually download the contents, even in the best case

The only useful case I can think of is this one:

· I make a new package which declares two dependencies, for example, and lets say both are on PyPI – ‘Dep A’ and ‘Dep B’

o ‘Dep A’ has direct dependency “foo>=1.0@ git+https://github.com/bar/foo.git@some-ref”

o ‘Dep B’ has direct dependency “foo>=1.5@ git+https://github.com/bar/foo.git@some-other-ref”

· A resolver _could_ use this information to determine that actually, it’s correct to use the version declared by ‘Dep B’

· This highlights the important distinction here:  just like with normal packages, the specifier is still being used to dictate which versions of foo would satisfy the requirement, _not the version that is currently found at the given url_

· Similarly when I specify a constraint such as “setuptools>=38.2” I don’t know which version I will get when I perform the installation or resolution, but I will be able to step through the resolution and compare other appearances of “setuptools”

· This starts to feel like the question I asked in the other thread—what happens if you supply a specifier and we find a better match on PyPI?

o I feel like this complication starts to unravel the purpose of a direct url; it should not be compared – I’m guessing we’d want to either fail resolution or privilege the URL if the downstream constraint isn’t satisfied by the provided direct url

· So that leaves me with -- specifiers may be useful for comparison but _only_ for comparing direct url subdependencies

Dan Ryan

gh: @techalchemy // e: dan@danryan.co

From: Tzu-ping Chung [mailto:uranusjr@gmail.com]
Sent: Tuesday, January 29, 2019 11:56 PM
To: Donald Stufft
Cc: Distutils
Subject: [Distutils] Re: Update PEP 508 to allow version specifiers

On 29 Jan 2019, at 23:19, Donald Stufft <donald@stufft.io> wrote:

On Jan 29, 2019, at 10:15 AM, Xavier Fernandez <xav.fernandez@gmail.com> wrote:

I agree that such specifier would make little sense but why add a new syntax "foo-1 @ url" when "foo==1 @ url" (where ==1 is a version specifier as defined in PEP 508) would perfectly fit the bill ?

Well foo-1 wouldn’t work great because you can’t disambiguate between (“foo”, “1”) and (“foo-1”, None). But the reason for using a different syntax would be so people didn’t confuse the concept with the idea of version specifiers, since >=1.0 doesn’t make sense, if we allow ==10, then people will assume they can add >=10.0 and willet confused when it doesn’t work. A different syntax side steps that issue.

A >=10.0 specifier could still work, I think. Resolvers are implemented to calculate the union of specifiers, so any specifiers would do. Of course it does not make perfect sense, but I guess it could be interpreted as “you can find the package here, and I promise it satisfies the given specifiers.

TP

--
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/CTQH6ZR3FVCODND3NXQC34U6O4J6AVTM/