[HN Gopher] Show HN: Asdf Clone Written in Rust
___________________________________________________________________
Show HN: Asdf Clone Written in Rust
I think that asdf (https://asdf-vm.com) was a great idea for a
project. It helps consolidate installing and running different
programming languages into a similar UX. It also is built with a
plugin interface that makes it easy to build support for new
languages. However it is so slow. I was just testing `node -v` and
it was taking ~900ms. That kind of overhead is completely unusable.
My shell prompt uses runtimes inside of it for various things so
this effectively makes every command take multiple seconds to
complete. So I rebuilt it in Rust but using the same plugin
ecosystem so it should be a drop-in replacement. I also added a
couple of features that I wanted from asdf (aliases and fuzzy-
matching). Let me know what you think! Just know that people have
only been using this for a few days so if you see any bugs, they're
likely not big hairy issues, just overlooked edge-cases and will be
fixed soon. https://github.com/jdxcode/rtx
Author : jdxcode
Score : 44 points
Date : 2023-01-30 17:22 UTC (5 hours ago)
| mystickphoenix wrote:
| This looks great, will be working with this in the next few days.
| I've always had a bad relationship with asdf as it seems to break
| existing tool management in creative ways that I'm unable to
| untangle without uninstalling it completely (long story, much
| thrashing of keyboard and mouse).
| moomoo11 wrote:
| The alternative to asdf (at least for me) is to just quit
| programming. It does what it is supposed to do well enough
| because in years I have not found anything better or necessary
| to replace it with.
| e12e wrote:
| > ... asdf as it seems to break existing tool management in
| creative ways
|
| Do note that asdf re-uses existing tooling, so trying to
| combine ruby-build and node version manager _and_ asdf with
| node and ruby plug-ins is likely to crash and burn (because you
| end up forcing existing tooling to fight with itself).
|
| Not sure if this was what caused your problems - but my asdf-
| life got a lot more pleasant when just asdf all the things
| (that I use).
|
| Does mean that things like vs code needs the right environment
| / local tool versions and language servers to work with your
| projects and vs code plug-ins.
| letmeinhere wrote:
| I like the idea, maybe I'll try it soon. I've recently been using
| asdf-direnv, configured to switch environments once, manually,
| and so taking shims out of the $PATH. Definitely giving up a bit
| of the magic for speed, so not sure if I love the tradeoff.
| bin_bash wrote:
| my issue with that solution is it makes directory changes with
| `use asdf` in the envrc slow. Of course that's not as bad as
| making all of the runtimes slow, but still intolerable IMO.
| jordemort wrote:
| I actually view being written in shell as an advantage for asdf.
| That means I can just submodule it into my dotfiles and bootstrap
| my tools without extra steps, no matter where I end up.
| nicoburns wrote:
| Ohh, this interesting. I love most things about asdf, but not the
| fact that it's great big heap of bash scripts. I wonder how hard
| it would be to get this working on (non-WSL) windows and how a
| truly universal version manager.
| bin_bash wrote:
| that would be unrealistic at least for now. The plugins are all
| written in bash. You'd first need to rewrite enough plugins for
| it to be useful. Maybe at one point if rtx takes off I could
| look into having plugins be in an alternate form though.
| danfritz wrote:
| Will definitely check this out! I'm a long time asdf user but I
| always struggle with the shims and long timeouts.
|
| I occasionally hit 2sec until my node version is resolved.
| happens wrote:
| Nice! I tried something similar at github.com/happenslol/qwer,
| I'll look at yours to see what you did differently :-)
| DavyJone wrote:
| Nice! How long does `node -v` take now?
|
| EDIT: OK, I see the main trick is to use PATH instead of shims.
|
| > rtx does not use shims and instead updates PATH so that it
| doesn't have any overhead when simply calling binaries
|
| There is a good reason `asdf-vm` uses shims, and is that it does
| not have to interplay or worry about other tools that set PATH
| and tools that need a reference to an executable could be simply
| set to `~/.asdf/shims`.
|
| Ill take it for a spin, but this choice might have a lot of
| consequences that are not easy to foresee. A good example is
| `direnv` which as you mention in the README now requires to be
| set in `.envrc` and then disable global `rtx` hook I guess.
| bin_bash wrote:
| direnv does cause problems, but there is a workaround that
| functions (calling rtx within direnv). The main problem is it's
| annoying since you need .envrc and .tool-versions file littered
| through your apps (or just .envrc with "export
| RTX_NODEJS_VERSION=18")
|
| There are some short term issues but I think I can resolve them
| in a way that direnv can't since I know exactly what PATH
| variables I added and didn't add. (Just remove everything with
| ~/.local/share/rtx prefixes.)
|
| I could also just implement shims like asdf. The performance
| cost would be negligible (2-3ms of overhead for me running `rtx
| exec -- node -v`). I hate shims because they break `which node`
| though.
| sigmonsays wrote:
| Obligatory "Written in Rust " after everything written in rust is
| still funny to me.
| digianarchist wrote:
| Glad to see you fixed what I think is a bad UX decision by asdf,
| using the subcommand `add` for plugins and `install` for runtime
| versions.
| jdxcode wrote:
| They nailed the back-end stuff. I would not have come up with
| such a good, simple plugin design. But yeah, there are several
| UX issues like this. Part of it is because it's written in
| bash, but ones like this I really couldn't explain.
|
| I'm trying to fix them while also supporting their syntax where
| I can, muscle memory is strong. So I support "plugins install"
| and "plugins add" If you notice any aliases that you think
| should exist, please mention them.
| ecnahc515 wrote:
| This is awesome. Have you seen http://tea.xyz? Made by the
| creator of brew. I think it has a lot of interesting ideas,
| especially since it also has some of the same features as
| asdf/venv/rbenv/etc: managing multiple versions.
|
| Figured I'd mention it, because I haven't tried tea yet, but I'm
| an avid asdf and brew user and I've been looking at asdf
| alternatives.
| codethief wrote:
| Great to see someone is trying to provide a better alternative to
| asdf!
|
| > aliases and fuzzy-matching
|
| What exactly does fuzzy matching mean? The only examples I see in
| your README are of the nature rtx install
| nodejs@20.0.0 Install a specific version number rtx
| install nodejs@20.0 Install a fuzzy version number
|
| How is this different from doing specifying `nodejs@20.0.x`
| (which I guess asdf doesn't support)?
|
| In any case, I hope that, if I try to install a package/plugin
| and it doesn't exist, it won't just try to install a
| plugin/package whose name is similar? :nervous_look.jpg:
| bin_bash wrote:
| What you described is fuzzy matching, basically just prefix
| matching.
|
| asdf has a handful of commands that let you do prefix matching
| like `asdf install nodejs latest:20.0` but they're not
| supported in `.tool-versions` files. This basically just adds
| that functionality.
|
| I didn't feel like requiring `latest:` was necessary. I felt it
| was clear that `nodejs 20.0` means `nodejs 20.0.*`. This is how
| npm has always worked.
___________________________________________________________________
(page generated 2023-01-30 23:00 UTC)