Comments (6)
@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.
from proto.
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
from proto.
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
from proto.
I think for this kind of stuff, we can use prerelease or build metadata
I strongly disagree.
- 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!
- 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.
- (most importantly) SemVer has precedence rules. E.g.
7.3.13+pypy-3.10
must compare higher than3.12.0+cpython
, whereas URLs are opaque. We definitely don't want to imply false compatibility or comparability.
from proto.
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.
from proto.
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!
from proto.
Related Issues (20)
- Proto removes comments when it modifies TOML files HOT 1
- Feature request: Allow snake_case for plugin ids HOT 5
- Proto Node.js can't execute `corepack` HOT 4
- Feature request: Pinning TOML plugins HOT 4
- Feature request: Plugin checksums HOT 6
- Feature request: Custom locators HOT 3
- Windows: proto uses `\n` when editing `$profile` (should be `\r\n`)
- Improve error message when xz is not installed in the system HOT 4
- version_suffix is no longer respected for VersionSpec::Alias
- proto install pnpm doesn't work HOT 10
- What would you like to see in proto? HOT 10
- `proto outdated` shows misleading error when it fails to resolve version HOT 14
- proto outdated --update clobbers non-version settings HOT 1
- proto use command causes error HOT 1
- [Windows] "proto regen [--bin]" always throws the error "proto::tool::invalid_dir" HOT 9
- Inventory directory error in all *but* Home dir (Debian) HOT 6
- Feature Request: Profile or Environments to e.g. only install some tools in CI HOT 3
- Plugin Removal Leaves Config Entries Intact HOT 2
- Inhancement of node.js version detections HOT 1
- missing_binary error when proto and proto-shim installed in /usr/bin HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proto.