Feature request: url version specifiers about proto

[milesj]

@rotu Do you have an example URL?

I think this would take quite a bit of work because of all the version resolving/checking that proto does.

[rotu]

So my initial intent here was so that I could install nightly builds that don't have a stable versioning scheme, e.g. canary builds like:
https://nodejs.org/download/nightly/v22.0.0-nightly202311184e23d6904c/

The other intent was to use a patched or alternate implementation ( e.g. pypy from https://downloads.python.org/pypy/pypy3.10-v7.3.13-win64.zip )

But perhaps these needs are better met by creating a TOML Plugin

[milesj]

I think for this kind of stuff, we can use prerelease or build metadata: https://docs.rs/semver/1.0.21/semver/

• 22.0.0-nightly.202311184e23d6904c
• 7.3.13+pypy-3.10

[rotu]

I think for this kind of stuff, we can use prerelease or build metadata

I strongly disagree.

1. URLs allow getting a package from a fork or other resource that is not a release. It's reasonable that some build does not have a compliant version number (if a version number at all) like from a pull request, or that a fork changes the version number in a strange way, or even changes versioning scheme like ChronVer!
2. The version is defined by the package maintainer and it's inappropriate to edit it, especially in a way that could collide with the package maintainer's own metadata. If we want to add info in a structured string, I recommend doing so with a character that is lexically illegal for SemVer.
3. (most importantly) SemVer has precedence rules. E.g. 7.3.13+pypy-3.10 must compare higher than 3.12.0+cpython, whereas URLs are opaque. We definitely don't want to imply false compatibility or comparability.

[milesj]

The main issue right now is that most of the internals right now are powered by semver::Version, like inventory management, folder names, and version detection/resolution. Supporting URLs breaks all of those guarantees, and I'm not entirely sure how much work it would take to migrate away from it.

[rotu]

The main issue right now is that most of the internals right now are powered by semver::Version, like inventory management, folder names, and version detection/resolution. Supporting URLs breaks all of those guarantees, and I'm not entirely sure how much work it would take to migrate away from it.

This feature is not a big need for me right now - it just seems like a good idea to keep in mind and a useful potential "escape hatch" e.g. if I need a patched version of npm instead of the official release. Or if I need to choose between packages of a specific Node release a la #137.

Conceptually I think about it as:

• An alias, channel or version range disambiguates to a version
• A version and an environment (OS, architecture, preferred archive format) resolves to a URL
• That URL locates the files to be installed.

The reverse direction is not always possible (e.g. going from a version to the requested range) and the forward direction is not always reproducible (new releases happen), so if it's important to keep that info around, it should be saved in the manifest.

No pressure to migrate unless it makes the code better!