Description
Sub-bug of #5677
Rustpkg should support pkgids with version numbers in them, rather than treating versions as a separate component of a dependency specification. The easiest thing I can think of is to use a URI-like fragment-specifier: path/to/pkgid#version
. Then version
is passed through somewhat directly to the underlying fetch mechanism (as a revision identifier -- either a tag/ref or a hash) and is mapped into a (sub)directory when checking out and building packages. We can start with specific revisions and extend to accepting revision-ranges (say, separated by ..
) in dependency requirements at some point if we find this is something people want.
Note that this is not in opposition to using semvers. We should encourage revision tags that are semvers. But users will occasionally want or need to refer to non-semver tags:
- Users who just want
HEAD
of some repo, while doing development - Users who need a specific ref (by content-hash) that has no associated semver
We can (probably?) differentiate cases using the following algorithm (though it's getting tight):
- Split any version-specifier at a
..
pair. If there's such a pair, it's a version range. If not, it's a single version. - If there is a
.
in a version, try to parse it as a semver. - If not, or if semver-parsing fails, consider it as an exact VCS revision identifier (tag, ref, etc.)