Show HN: I made a multiple runtime version manager that can be used on Windows
Comments
lxe
aooohan
Yes! Compared to asdf, vfox has made some UX improvements to make the commands more concise.
eclipsetheworld
This looks really cool! Working on multiple projects with different versions before tools like pyenv or nvm existed was a real challenge. As someone working with different programming languages as well, this tool looks like the next logical step.
rjzzleep
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
magnio
I wanted to like asdf but 1. it's slow, and 2. not available on Windows proper (non-WSL). Same with mise (https://github.com/jdx/mise) which builds on asdf.
Volta exists but alas, it's only for JavaScript.
gorjusborg
I know asdf doesn't work in windows outside of msys/WSL, but I've never seen evidence that it is 'slow'.
aooohan
I've used all of these tools in conjunction with my own usage habits, which is why I'm developing vfox from scratch rather than based on asdf. so the issue at hand for vfox is the need to rebuild the plugin ecology. There's no way to utilise off-the-shelf asdf plugins.
rjzzleep
I just looked at your plugin-template. This sounds good actually. Writing asdf plugins can be quite nasty. I like the approach of adding a lua dsl for plugin generation, not sure I like the dsl itself.
aooohan
But it does nothing for Windows.
devmor
pyenv is still the best solution to this problem I have yet to see - wish it existed for everything
tyingq
It does have upsides. Though the python runtime version management story suffers from being fragmented. It gets complex if you add poetry, IDEs, different types of shells (gitbash, power shell, zsh, etc), things that have their own ideas of environments (Jupyter as one example).
aooohan
Honestly, the python plugin is a bit problematic on Windows at the moment, the next plugin version should fix that.
But on unix it is also built using python-build. For me, a light python user, there is no difference between using vfox and using pyenv.
tambourine_man
This looks super interesting, I’ve been thinking of building something like this for a while. A list of available runtimes would be nice to have. Thanks for sharing.
happyweasel
Can someone please explain to me what this does? I have 25y exp in the industry but I did not Understand the use cases by reading the GitHub page..
WorldMaker
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.
vbezhenar
I just unpack node to different folders and set PATH. Why would I need any tool for that?
Most languages work that way just fine. Java, node, python, go. The only bad player that I've found is Rust, its distribution is absolute mess.
WorldMaker
Sure, these tools don't do much more fancy than that. The early days of pyenv was "just" a tool that output a Bash script that set PATH and PYTHONPATH and a few other environment variables.
There's still some utility in automating changing your PATH when you switch between projects: do you need to support multiple shells with different syntaxes for changing environment variables? Do you need to synchronize those shells sometimes? Do you need to change PATH for random combinations of multiple tools at once? Do you want to have a tool verify for you that you are changing PATH to refer to a version currently installed? And maybe automate installing it if isn't?
This particular tool supports a half-dozen different shells (on Windows) and a single file to setup PATH (and other environment variable changes) for any number and combination of tools all at the same time.
If you are happy with your manual PATH changes today and don't see a reason to automate them, then you might not need a tool to automate them. If you find yourself changing PATH a lot more frequently and hoping to automate it more, there are tools for that. As with anything, automation is a spectrum and what you might not do enough to automate someone else might do a lot more often than you and could use some form of automation to speed things up and/or catch easy or dumb mistakes.
aooohan
> I just unpack node to different folders and set PATH. Why would I need any tool for that?
To put it simply, vfox will help you do this. Unzip node, golang, etc. to $HOME/.version-fox/cache. When you write `vfox use node@10.1.1`, it will automatically configure PATH for you. Free your hands, you don't need to think about where to download nodejs, golang, etc. runtime, nor how to configure PATH. Especially on Windows, configuring PATH is still quite troublesome.
swozey
"Why make my life easier?"
I deal with hundreds of different repos/projects that use various versions of various runtimes and I have to switch versions sometimes multiple times a day, sometimes multiple times a week.
Why would I want to unpack an entire language runtime into ANOTHER directory when I can enter the directory and write "nvm use system"? And if I want to install a specific version of node, without having to dig around for the url on nodejs' website I write "nvm install 21.7.3" and it installs it. Then I use it.
Like, it's practically weaponized incompetence to just dig your head in the sand and not use these practically standardized tools that everyone else has been using for 15+ years. Do you dislike using package managers as well? Apt? Nix?
I don't feel like dealing with HNs terrible formatting system but this is how much work I do to install and change versions of one runtime. I deal with TONS of runtimes throughout the week.
Also this is just one runtime, I also have to deal with python, ruby, go, terraform and many other versions so these "aggregate" runtime version managers like asdf etc are awesome.
######
-> (base) workspace nvm list
-> system
iojs -> N/A (default)
node -> stable (-> N/A) (default)
unstable -> N/A (default)
-> (base) workspace nvm use system
Now using system version of node: v21.7.3 (npm v10.5.0)
-> (base) workspace nvm install 21.7.3
Downloading and installing node v21.7.3... Downloading https://nodejs.org/dist/v21.7.3/node-v21.7.3-darwin-arm64.ta...... ############################################################################################################################################################ 100.0% Computing checksum with sha256sum Checksums matched!
Now using node v21.7.3 (npm v10.5.0)
Creating default alias: default -> 21.7.3 (-> v21.7.3)
-> (base) workspace nvm use 21.7.3
Now using node v21.7.3 (npm v10.5.0)
wongarsu
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
httpsterio
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.
lxe
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.
Dobbs
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.
happytoexplain
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.
newzisforsukas
> A cross-platform and extendable version manager with support for Java, Node.js, Flutter, .Net & more
Seems pretty clear to me?
ddsgtuuuu
What are the benefits of this over dev containers? (I just do BE and web stuff, so maybe it's just not for my use case)
Kuinox
I do not understand the usecase for dotnet, since the dotnet SDK self select the correct version to run the project. You never need to change the version yourself. On my current machine:
PS C:\Users\username> dotnet --list-sdks
7.0.408 [C:\Program Files\dotnet\sdk]
8.0.101 [C:\Program Files\dotnet\sdk]
8.0.104 [C:\Program Files\dotnet\sdk]
8.0.204 [C:\Program Files\dotnet\sdk]
8.0.300-preview.24118.4 [C:\Program Files\dotnet\sdk]
AaronFriel
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.
SEXMCNIGGA48890
[dead]
SEXMCNIGGA21664
[dead]
SEXMCNIGGA32577
[dead]
SEXMCNIGGA12876
[dead]
SEXMCNIGGA44060
[dead]
SEXMCNIGGA43114
[dead]
SEXMCNIGGA13016
[dead]
SEXMCNIGGA24418
[dead]
SEXMCNIGGA8456
[dead]
SEXMCNIGGA23434
[dead]
SEXMCNIGGA12704
[dead]
SEXMCNIGGA16300
[dead]
SEXMCNIGGA30577
[dead]
SEXMCNIGGA33697
[dead]
2genders38534
[dead]
SEXMCNIGGA28622
[dead]
2genders11185
[dead]
SEXMCNIGGA36211
[dead]
SEXMCNIGGA17955
[dead]
SEXMCNIGGA37207
[dead]
SEXMCNIGGA49135
[dead]
SEXMCNIGGA35766
[dead]
2genders10340
[dead]
SEXMCNIGGA13800
[dead]
2genders35117
[dead]
2genders38457
[dead]
2genders8748
[dead]
2genders12597
[dead]
2genders14511
[dead]
2genders45975
[dead]
2genders22926
[dead]
tiffanyh
Cygwin?
I'm not exactly understanding the use case for this.
Is this like a modern day Cygwin?
aooohan
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.
2genders1784
[dead]
2genders29230
[dead]
2genders23409
[dead]
2genders47151
[dead]
2genders111
[dead]
2genders29231
[dead]
SEXMCNIGGA25001
[dead]
SEXMCNIGGA6632
[dead]
SEXMCNIGGA39790
[dead]
SEXMCNIGGA37272
[dead]
indianmilf3250
[dead]
indianmilf19561
[dead]
indianmilf41790
[dead]
2genders2170
[dead]
2genders19276
[dead]
2genders17397
[flagged]
indianmilf13445
[flagged]
indianmilf2461
[flagged]
indianmilf47583
[flagged]
2genders48585
[flagged]
2genders48347
[flagged]
2genders45256
[flagged]
2genders38534
[flagged]
2genders20141
[flagged]
2genders22571
[flagged]
2genders17675
[flagged]
2genders14517
[flagged]
2genders34179
[flagged]
SEXMCNIGGA4002
[flagged]
SEXMCNIGGA42999
[flagged]
SEXMCNIGGA20586
[flagged]
SEXMCNIGGA39403
[flagged]
SEXMCNIGGA22020
[flagged]
SEXMCNIGGA42378
[flagged]
SEXMCNIGGA19094
[flagged]
SEXMCNIGGA13410
[flagged]
SEXMCNIGGA11171
[flagged]
SEXMCNIGGA47027
[flagged]
SEXMCNIGGA23726
[flagged]
SEXMCNIGGA4805
[flagged]
SEXMCNIGGA842
[flagged]
SEXMCNIGGA15056
[flagged]
SEXMCNIGGA27825
[flagged]
SEXMCNIGGA24807
[flagged]
SirFatty
Yes, how did you know?
SEXMCNIGGA47555
[flagged]
SEXMCNIGGA16456
[flagged]
SEXMCNIGGA27614
[flagged]
SEXMCNIGGA46881
[flagged]
SEXMCNIGGA34084
[flagged]
SEXMCNIGGA39314
[flagged]
SEXMCNIGGA7539
[flagged]
SEXMCNIGGA13481
[flagged]
2genders35412
[flagged]
2genders49246
[flagged]
SEXMCNIGGA8997
[flagged]
SEXMCNIGGA8068
[flagged]
SEXMCNIGGA10383
[flagged]
2genders47485
[flagged]
2genders27181
[flagged]
ahai
This management tool vfox looks very flexible, especially when it comes to plugin builds, I found that it already supports versioning of a lot of major software, and software that I don't use often can be built very quickly according to the manual and without having to upgrade the tool's version, it looks very silky smooth, and also supports multiple platforms, which is going to be very easy to use. I can't wait to use it and hopefully it will help me be more efficient.
Killer features are 1. windows support, and 2. reading .tool-versions file, meaning that you can migrate from asdf with no issues.