Core plugins

[jdx]

Some plugins are so fundamental I think they should just be fully baked into the CLI like nodejs, Python, and ruby. I actually think we could probably do this with most of the common languages so most users wouldn’t need plugins at all.

By this I don’t mean the shorthand would be baked in (like today), but the entire plugin with bin/install and everything.

This enhances security a bit by removing one vector for vulnerabilities to come in, also it will modestly improve performance by not needing to fetch the plugin. We could go a step further by baking in Python-build and node-build as well.

In terms of how this would work I think we’d take the asdf plugin and import it into the project using subtree or submodule (we will likely modify them slightly). Then we package it into a tarball which would be added into the rust cli as an artifact.

From there it would work the same way, extracting to local/share and everything.

• python
• nodejs
• ruby
• java
• golang

[jdx]

python is now in but I want to do this for node, ruby, and java as well. The first one was definitely the hardest, so the rest should be a lot easier.

[jdx]

added golang to mitigate #488

[jdx]

I'm actually surprised and glad to see so many people gave a thumbs up on this, right now it's by far the top requested feature by reaction count. I am curious why you want this though, is it security? performance? or just the idea that rtx is more self-contained?

[jimeh]

@jdxcode Personally I'd say it's a most of all a matter of reliability/trust, and secondly a matter of security and performance.

Specially for the most central/core things like common programming languages that people depend on daily to do their job. Having more of a first-party status in rtx will only help to increase trust in the ability to manage those tools with rtx.

Personally, the uninstall operation sometimes makes me a little nervous for some of the more obscure tools/plugins, as the uninstall binaries often run things like rm -rf [...]. And a simple typo in a plugin could lead to a sad day for many people. Anyone remember the extra space typo in the Steam updater script a decade ago? It was something like rm -rf / usr/local/steam.

That said, the chance of such a bug is a mostly acceptable risk for the flexibility of a wide open plugin ecosystem that anyone can contribute to. Besides, we make regular/automated backups, right? ^_^

[roele]

Initially i used my own fork of asdf-java because of somewhat annoying dependencies to asdf bash scripts. Even though there was already a PR on the asdf-java repository to resolve this, there has been no response until today. Therefore i think having core plugins would give users a central place to look for and maintain rtx specific forks/plugins instead of creating their own. Additionally in the future these could provide features asdf does currently not support.

[jimeh]

Just a small question/note about the Ruby core plugin. May it be worth evaluating ruby-install for use in the core plugin, rather than ruby-build?

Ruby-install has been on my list of things to try for a long time, primarily because ruby-build requires an update whenever a new Ruby version is released, while ruby-install dynamically fetches a list of available versions, so typically no need for an update when a new version is released.

@jdxcode I don't know how familiar you are with Ruby in general, but if you want, I'd be happy to provide any support I can. I've been working with Ruby since around 2008, so I'd like to think I'm fairly aware of what makes a good installation of Ruby... lol :)

[jdx]

perhaps. I did some testing with these and found ruby-install to be significantly slower than ruby-build if memory serves though