Show HN: I made a multiple runtime version manager that can be used on Windows (opens in new tab)

Yes! Compared to asdf, vfox has made some UX improvements to make the commands more concise.

asdf works great for that purpose. And you can either use a single .tool-versions file or enable legacy support for compatibility with pyenv rbenv etc.

Plus is supports many more tools than just the language vms

https://asdf-vm.com/

pyenv is still the best solution to this problem I have yet to see - wish it existed for everything

It's a tool for managing environments for side-by-side installs of different versions of developer tools. Say you've got multiple projects you are working on and some need Node v18 and others Node v20 and some of each need Python 3.10 or Python 3.11 depending. You can handle switching side-by-side Node installs with a tool called nvm and there are lots for side-by-side Python switching (pyenv, pip env, conda, so many more), but maybe sometimes you want to manage both together ("this project uses Node v18 and Python 3.11"). This a tool for doing that combined development environment switching, supporting plugins for a number of ecosystems like Node and Python.

It's an alternative approach to what containers do. (Or an alternative to strict version policies such as "all Node and Python should be done with current LTS, no exceptions".)

There are similar tools on Linux, so the noteworthy thing about this one is it is Windows native.

Suppose you have one project that only works with the newest Node 20, and another only works with Node versions 16-18. So you want a tool that takes care of installing both versions and gives you an easy way to switch between them, either globally or only for the current shell. Maybe with some autodetection via config files that can be put in the project folder.

That's basically this. But not bespoke for node (like nvm) or python (like pyenv) or protobuf, but as one tool that promises to do this for all your tools

it allows you to install multiple versions of different code compilers and interpreters and change which version is used.

so for example you can install nodejs lts and latest side by side and then easily swap which version is currently used when running node.

There are already tools like nvm (node version manager) that does the same but this one works for multiple tools instead of just one.

Curious what your experience is. I'm guessing there are dev cultures where tooling versions never have to change across projects, which has its pros and cons.

For most of my career at large tech orgs working with node.js/frontend stack, python, go, and even java, I always needed things like conda, nvm, etc...

Heck, even working with C (and CUDA), I would love to have an easy way to switch system-wide C/CXX compiler versions.

You are working on project A, and project B. Project A uses python 2.6, project B uses python 3. You want a simple way to switch back and forth without reinstalling everything every time you switch between them. This setups a way to quickly and if I'm understanding correctly automatically switching between the two versions of the tool.

Replace python with many other tools from Java, node, etc.

Thanks for asking the question I am perpetually too embarrassed to ask. As somebody who spends 95% of my time doing native mobile, I rarely have to think about this problem. I'm sure "runtime version manager" resolves to a specific idea for most people, but it was too general for me to know what it was referring to, even after reading the elevator pitch (my first thought was: like Docker?).

This happens to me all the time. I wasn't formally educated and didn't spend my formative years around computer people. So I have holes in my knowledge and misunderstand parlance if it's not specific to my personal 10% of the software world. E.g. in the beginning, it took me a few years to realize that when people say "frontend", they virtually always mean web frontend.

> A cross-platform and extendable version manager with support for Java, Node.js, Flutter, .Net & more

Seems pretty clear to me?

For runtimes with tooling like .NET has, it's a niche use case.

At $dayjob, we have to support non-current compilers/SDKs for five different languages and runtimes where our tool will invoke (shell out, often) the CLIs for those tools. When triaging a bug report, it's great to have a version manager to use exactly the customer's version of the CLI.

Likewise, we need to make sure all of our examples and templates build even if the user has an old version, and the surest way to validate that is to hide newer CLIs and tools, and to test on the range of binaries that a customer could have installed.

No, these are two completely different tools.

Compared to Cygwin, vfox is just a small tool which is more like scoop.

Simply put, while scoop can only install the latest version, vfox can install any version, and has some extra features for project development, such as using different versions for different projects, automatic switching between versions, and so on.