search

moonrepo / proto

A pluggable multi-language version manager.
https://moonrepo.dev/proto
MIT License
663 stars 32 forks source link

Feature request: url version specifiers #331

Open rotu opened 10 months ago

rotu commented 10 months ago

Currently, tool version specifiers are channels or version numbers. It would be nice if, instead, I could install and pin specific versions (e.g. nightly builds) by URL.

milesj commented 10 months ago

@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 commented 10 months ago

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 commented 8 months ago

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

rotu commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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:

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!