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:

• https://github.com/asdf-vm/asdf/issues/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.

[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