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