Feature request: upgrade and/or clean support

[eproxus]

I install multiple major latest version of a tool, e.g. erlang@25, erlang@24 and erlang@23 (standard in the Erlang ecosystem is to support the three latest major versions). It's easy to automate upgrading to the latest major versions using rtx:

$ alias upgrade_erlang='rtx install erlang@25 erlang@24 erlang@23'

There are two downsides to this approach:

1. The alias has to be updated whenever a new major version is released
2. It leaves the old versions lying around

The following are some suggestions for syntax and commands:

To solve (1) it would be nice with some support to install previous major versions.

$ rtx install erlang@latest erlang@-1 erlang@-2
...would install the latest erlang and the two previous major versions

A clean command of sorts would also be useful to solve (2). The command would uninstall all older versions than the latest major versions. An example (again, only a suggestion):

$ rtx list
  -> python     3.11.0 (set by ~/.tool-versions)
     python     3.10.0
     python     2.7.18
     python     2.7.14
     python     2.7.10
$ rtx clean python
...would uninstall python 3.10.0, 2.7.14 and 2.7.10
$ rtx list
  -> python     3.11.0 (set by ~/.tool-versions)
     python     2.7.18

Apologies if this is outside the scope of rtx or has already been suggested or solved (if so, please let me know!).

[jdx]

these both sound pretty useful. I remember seeing one of the version managers supporting some kind of "lts-1" method of using the last major version. I think that could be useful in a CI project where you just want to focus on the most current major releases and not need to update it.

[z0w13]

There's also https://endoflife.date which might be useful for this in some way (at least as a reference)

[jdx]

yeah maybe if you wanted to say "all non-eol versions of node" with some syntax

[jdx]

This is really complicated since there are like 4 use-cases I can think of here.

1. upgrading nodejs@16 to latest version of node-16

I feel we don't need this anymore with some behavior changes that have gone in. nodejs@16 points to the latest available, not the latest installed version of node-16*. If that's not installed, rtx activate will show a warning by default but that can be overridden with RTX_MISSING_RUNTIME_BEHAVIOR=autoinstall. I think just needing to run rtx install does what you need, rtx upgrade wouldn't offer anything for this use-case.

(* this is cached and if only ever use rtx activate you would never get a newer version, that logic is too complicated to describe here, but if you just ran rtx install with no args occasionally you'd effective be upgrading the patch version in a fuzzy-matched .tool-versions)

2. removing old runtimes

I get that you only want a single version of a runtime (say only the most recent version of nodejs@16), but I'm not sure I like rtx upgrade as the solution. In that scenario, the only difference between rtx install and rtx upgrade would be that the latter removes old runtimes.

I know that's what you want, but it feels surprising (in a bad way) to me that this would be the difference in these commands. Maybe I'm wrong.

I think there are actually 2 other use-cases that you didn't bring up but are actually what I was more interested to get out of rtx upgrade.

3. modifying .tool-versions beyond what is specified in .tool-versions.
4. same as above but interactively

I think yarnv1 does both of these pretty well with yarn upgrade and yarn upgrade-interactive. In asdf, there is a thread where they discussed this too:

• Interactive .tool-version updates asdf-vm/asdf#1235

What I need to do is look at other package managers and see what's common and what would work best for rtx. I think "upgrading" is very useful, we just need to figure out what it should mean exactly.

[leipert]

Ha, just saw this discussion after I've created: #479

[eproxus]

@jdxcode I wasn't so much referring to keeping a set of already installed fuzzy version up-to-date, more to moving from one fuzzy set to another. I also don't need rtx upgrade per se (I just happened to call my alias "upgrade").

Points 1-4 in your reply doesn't really cover "requirement" (1) which is being able to automatically move to a new set of installed major versions. If I understand it correctly, 1 is about upgrading a major version to its latest minor update (this seems covered by rtx install and the auto installation setting as you said). 3 and 4 is not applicable because this is about all the installed version of a tool, not just the activated one.

Regarding 2, I would be fine with building my own "upgrade" task, but I'd ideally have the proper support in rtx so I don't have to hard code things or parse output (e.g. to figure out if a new major version was installed when using latest) which would make such a script incredibly complex.

[jdx]

thanks for clarifying. It sounds like what you want is to be able to do something where effectively the .tool-versions file would go from this:

nodejs 18

to this:

nodejs 20

is that right? It would be possible to do this today with rtx local --pin, but that would put full versions in which it sounds like you're trying to avoid, do I have this right?

Also see #221 which is related to this (but doesn't cover that use-case). I think the combination of rtx install && rtx prune would be a better solution than a single command to try to do both things.

[jdx]

Perhaps the way it would work would be:

$ rtx local nodejs@16
$ rtx upgrade nodejs # upgrades to "18"
$ rtx local [email protected]
$ rtx upgrade nodejs # upgrades to "18.14"
$ rtx local [email protected]
$ rtx upgrade nodejs # upgrades to "18.14.1"

Where it would pick the latest version at the same precision that it was before. Does that sound right to you @eproxus ?

[eproxus]

I was imaging being able to have this in my tool versions file:

erlang latest

and then some kind of way of keeping the two previous versions installed, and in addition prune any older minor versions after upgrades.

I’m not advocating for a single command so that’s not a requirement. I want to avoid having to manually update scripts or aliases whenever a major version is released.

[jdx]

something like this?

erlang latest latest^1 latest^2

Where ^N means "subtract 1 from the first number of the latest version". This means for node you would do:

nodejs latest latest^2 latest^4

[jdx]

See #303 which has a new syntax that I think will be helpful for you here

[eproxus]

@jdxcode Unfortunately for my use case it doesn't seem to work:

$ RTX_DEBUG=1 rtx install erlang@latest!-1
[DEBUG] Files: ~/.tool-versions, ~/.config/rtx/config.toml
Installed Plugins: erlang, nodejs, python
[DEBUG] /opt/homebrew/bin/rtx install erlang@latest!-1
[DEBUG] erlang@latest, nodejs@latest, python@latest
[WARN] cannot subtract 1 from latest
rtx erlang@latest!-1 installing
Error:
   0: failed to install erlang@latest!-1
   1: ~/.local/share/rtx/plugins/erlang/bin/install exited with non-zero status: exit code 1

Location:
   src/plugins/script_manager.rs:239

Version:
   1.23.7 macos-arm64 (built 2023-03-14)

Suggestion: Run with RTX_DEBUG=1 for more information.

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

[jdx]

this was fixed in #341

[dhanak]

A clean command of sorts would also be useful to solve (2). The command would uninstall all older versions than the latest major versions. An example (again, only a suggestion):

$ rtx list
  -> python     3.11.0 (set by ~/.tool-versions)
     python     3.10.0
     python     2.7.18
     python     2.7.14
     python     2.7.10
$ rtx clean python
...would uninstall python 3.10.0, 2.7.14 and 2.7.10
$ rtx list
  -> python     3.11.0 (set by ~/.tool-versions)
     python     2.7.18

I solved this by setting multiple versions in the global .tool-versions, and using rtx install to upgrade and prune to delete old versions. Works like a charm:

$ rtx global [email protected] [email protected] [email protected] [email protected]
julia   1.8. 1.7 1.6 1.0

$ rtx ls
⏵  julia 1.0.5               (set by ~/.tool-versions)
⏵  julia 1.6.7               (set by ~/.tool-versions)
⏵  julia 1.7.3               (set by ~/.tool-versions)
⏵  julia 1.8.5               (set by ~/.tool-versions)

$ julia --version
julia version 1.8.5

$ rtx prune
...

The only downside is that rtx current returns multiple versions:

$ rtx current julia
1.8.5 1.7.3 1.6.7 1.0.5

[jdx]

#402 is going to lay some groundwork for this I think. With that improvement, calling rtx g nodejs@latest would actually just use the latest version previously installed (different than today, but I think it's better).

If you want to point @latest to the newest version you'll run rtx i nodejs@latest, however this would leave the old version around. I think we should add rtx upgrade nodejs@latest (and rtx upgrade nodejs for all aliases like 16 and lts).

What that would do is delete the old versions if they're not explicitly referenced like with prune.

[olfway]

It would be also great to have an easy way to upgrade all installed runtimes.
or is it already possible?

[eproxus]

I would like to see one or many commands that allows me to upgrade a moving window of the X latest major version of a tool. Ideally this would include some pruning/cleanup of outdated minor versions. I'm totally fine if I have to weave together some commands to achieve this though 😄

[jdx]

It would be also great to have an easy way to upgrade all installed runtimes. or is it already possible?

I don't think this is possible. I think I have to reference .tool-versions or .rtx.toml. If we take nodejs:

rtx upgrade nodejs

You would expect this to upgrade 18.0.0 to 18.1.0, not 18.0.1. You're only interested in upgrading nodejs@18, not upgrading [email protected]. However with Python you want both (upgrade python@3 and [email protected].

What I could do is make rtx upgrade --everywhere which would look at all .tool-versions/.rtx.toml files you've ever used.

@eproxus I don't know what you mean by this:

upgrade a moving window of the X latest major version

[eproxus]

I meant that I'd like the X (e.g. three) latest major versions installed and upgraded to their latest minor versions. If there are new minor version I'd like to get them (and prefer uninstalling older minor versions). If there is a new major version I'd like that to get installed and the oldest major version uninstalled.

[eproxus]

I'd be happy to achieve all this with multiple commands, but I don't think there is a set of commands today that will give this result?

[jdx]

apologies if someone mentioned this and I just didn't see it our get it at the time, but I just realized one area this can help with which is reusing dependencies. The way asdf/rtx works is that when you install a new version (even just a patch release), it is a totally clean install without any of the previous packages.

While that's definitely the safe way to do things, it's a huge pain because you need to reinstall everything. Many plugins have some kind of "default packages" feature to automatically install things, but that's slow and a pain to maintain.

I think rtx upgrade can help here. If you do rtx upgrade nodejs@18, then it could move the dependencies from the previous v18 version into the new one. The logic might be tricky here (what if you have 18.0.1 and 18.0.2 and you're upgrading to 18.0.3, does it take dependencies from both and merge them?)

So it's a hard problem, but I actually think reusing dependencies like this would be really helpful.

[leipert]

So it's a hard problem, but I actually think reusing dependencies like this would be really helpful

Just thinking about ruby and all it's gems with native extensions, I do not know whether it would be worth it. I am actually quite happy that a new install prunes the globally installed dependencies for ruby and node, and instead rely on the default-package-file thing.

Furthermore, also think about a case where you upgrade your ruby or pythin and then all dependencies are moved over and then you want to downgrade for whatever reason 🙈

[jdx]

that's a good point, it's only helpful in languages that have ABI compatibility across versions like node does for major versions. I think python has this for minor versions but unsure about ruby.

[jdx]

this could also be behind a flag. nvm has a --reinstall-from=current option, but I don't love that. I think if the ABI is compatible and you're upgrading (meaning the old version is being deleted), I think by default you will probably want the global packages.

[alper]

I'm trying to figure out how to do this. For node I:

rtx ls-remote nodejs 19.6

rtx install [email protected]

rtx global [email protected]
This doesn't seem to do anything on my system (rtx global still gives the same output), so I edited ~/.tool-versions and ran rtx i

And I have rust@nightly but I'm not sure how to regularly update it to be an actual nightly version.

[jdx]

This doesn't seem to do anything

what do you mean? it's not adding 19.6.1?

And I have rust@nightly but I'm not sure how to regularly update it to be an actual nightly version.

"nightly" versions are tricky. The plugin just presents "nightly" as a discrete version so rtx has no way to know the version has changed. For nodejs@lts, we can use aliases which map lts -> 18.0.0 or whatever, but that might not be possible for a nightly version since I don't think they actually map to a specific version. We may need to put the nightly git sha into a version number so that rtx is aware that it changed.

This will require either asdf-rust adding some rtx-only functionality (a bin/list-aliases script) or forking the plugin into rtx-rust.

[alper]

what do you mean? it's not adding 19.6.1?

Exactly. I fiddled with the file myself. Up until then I didn't even know this file existed.

This will require either asdf-rust adding some rtx-only functionality (a bin/list-aliases script) or forking the plugin into rtx-rust.

I can't really add anything at the development level to this. As a user I'd like to have a standard and documented way to keep the various (global) toolchains on my machine up to date.