[Distutils] distlib locator compares reasonably well with pip's PackageFinder

[Vinay Sajip]

PJ Eby <pje <at> telecommunity.com> writes:

 
> "dev" is the version, actually.  It's a perfectly valid version to
> setuptools, and parses as a version that's below any commonly-used
> version.  This lets people specify "==dev" to target an in-development
> version for installation -- usually manually, but sometimes
> automatically.  One might specify, for example "foobar>2.0,==dev" to
> tell setuptools that if you can't find a released version >2.0, then
> an in-development version is acceptable.

I get that, but the question is, should such a version (which could be
completely different tomorrow) appear by default e.g. when doing dependency
resolution, where no ==dev is likely to be specified? 

> If they're using a "dev" version, then such a link is automatically
> lower-precedence than anything else already, due to it being the
> lowest available version.(Newer tools could treat it as 0dev or
> whatever the official translation/suggestion is.)  In addition, it
> denotes a "non-stable" version, so if the tool allows one to
> prioritize stable versions, it'll be eliminated as a candidate anyway
> in that case.

In the failure cases I was noting earlier, there were no other versions. I'm
looking at the locate() mechanism not just as invoked directly from a user
request to install (where ==dev might well be specified), but also via
attempting to resolve dependencies - when it's not clear whether a version
such as "dev" should really be included.
 
> If the version tag is precise, OTOH, (i.e., something other than
> 'dev'), then presumably the provider of the link can be trusted to
> have identified what version it is.  IIUC, those source control sites
> let you download tarballs of arbitrary versions, so one could in
> principle issue download releases of exact source snapshots.  (Indeed,
> it's not a bad way to go about it.)

In cases where the URL specifies an archive named in the conventional way
(name-version.ext), then these are currently picked up, even from DVCS
hosting sites. What are not picked up are links which may contain the version
number, but not necessarily using strictly defined conventions. In such cases,
I would prefer not to add too many regex-style checks for various schemes which
might be in use, but just provide a minimal way for users who need it to slot
in these schemes via subclassing. After all, with the current setup, distlib is
picking the same download URL as pip for 98% of cases.

N.B. with the #egg=name-version scheme, as the fragment portion is not sent
to the server, there's no way to expect that the server will always return
a specific version (as no version is specified in the URL which goes to the
server). At least that's not the case when you ask for a resource with a
specific project name and version in the name of the resource itself.

Regards,

Vinay Sajip