Available Plugins: https://vfox.lhan.me/plugins/available.html
Supported Shell: Powershell、Clink、Cmder、Bash、ZSH
Plus is supports many more tools than just the language vms
Volta exists but alas, it's only for JavaScript.
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.
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.
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.
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
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.
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.
Replace python with many other tools from Java, node, etc.
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.
Seems pretty clear to me?
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]
IMO it's a better way to handle this sort of problem: the SDK self select which version should run, according to your project config.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.
I'm not exactly understanding the use case for this.
Is this like a modern day Cygwin?
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.