I have previously only used Nim on Linux and I just installed Nim on Windows. I wanted to install using Choosenim so it would be easy to update Nim. First it failed to copy some dll files like in this issue comment. Then I created .nimble\bin\ before running Choosenim and it seemingly installs Nim correctly. However the compiler doesn't actually compile anything. I created an issue about this.
The manual install method on https://nim-lang.org/install_windows.html works, but its not ideal. Normal Windows programmers are not used to extracting software and adding it to the path. Ideally Choosenim would just work more like other Windows installers. It should be a single executable that installs everything. It would also be nice if the installer automatically adds Nim to the user path. I checked and its possible to do that without admin rights at least in Powershell.
Maybe Choosenim shouldn't be mentioned on the "Install Nim" page for Windows while its in this state. Newcomers might try it first, and currently it seems completely broken with multiple Github issues about Windows.
Normal Windows programmers are not used to extracting software and adding it to the path
While I understand the general sentiment of the post, this sentence is baffling. Managing global and user PATH variables is a problem any Windows programmer faces sooner, rater than later.
Here's one tool that makes it a bit more tolerable: https://rix0rrr.github.io/WindowsPathEditor/
The issue as presented at Github is more likely the gcc conflict. I suggest managing your MinGW installation manually. Last time I checked, w64devkit has worked fine with Nim, except LTO which isn't used with Nim by default.
Whenever I've had to do development with Nim on Windows, it was always 10x easier to just install WSL and use choosenim there. I use WSL purely for the Linux utilities anyway so using it to compile Nim programs was a no-brainer.
But no one should be forced to use Linux purely because Windows support is poor to that degree.
There is a possibility that this has been caused by the changes in PR #38. But AFAICS that would mean that the MinGW "gcc" executable relies on argv[0] to contain the full path of itself to find "cc1.exe". I have to write a test to confirm that. Unfortunately a single CI test run can take up to 45 minutes, because it re-compiles some version of Nim several times during the run.
the issue reporter is a bit reluctant with sharing additional information about the issue, because they "think that its easy to reproduce this issue"
I did share all the relevant information as soon as I saw your replies on the issue. I didn't mean that it is easily reproducible. It was just a badly worded comment. My Windows install is so basic that I thought the issue would most likely be easy to reproduce for anyone on Windows.
There is a possibility that this has been caused by the changes in PR #38. But AFAICS that would mean that the MinGW "gcc" executable relies on argv[0] to contain the full path of itself to find "cc1.exe" (which would be unusual, IMO).
Its probably that PR. Choosenim 0.8.12 creates a working install. I don't see any other changes in Choosenim 0.8.14 related to the proxy executables. The only clear differences in the Nim installations made by Choosenim 0.8.12 and 0.8.14 were the executables in .nimblebin.
I disable virtualization in my BIOS to get the maximum gaming performance out of my Ryzen 5700x that is pretty old at this point. I'm going to port my Linux project that interfaces with a QMK keyboard over rawhid to switch keyboard layouts based on the current window title. I doubt that kind of a project would work in WSL or when cross-compiled to Windows through WSL. It uses Python libraries with Nimpy and I'm also going to use Winim for Windows API stuff.
Anyway the manual install of Nim 2.2.4 works just fine, so the Choosenim 0.8.14 bug is not a big problem for me.
You can try scoop to get working gcc and nim - no issues with paths (automatic path management), no need to choosenim, etc:
scoop install gcc
scoop install nimOk there is actually nothing wrong with the install experience of the manual install. My main problem was that if Choosenim is advertised as an installer with easy version switching, it should just work by opening an executable and following the prompts.
Also after writing this I found out that both the manual install and Choosenim don't actually require editing path by hand. Choosenim just doesn't clearly say that it already added the Nimble bin dir to path.
Ok, I finally managed to to write a test for the CI that reproduced the problem.
choosenim really was not written with easy testing in mind. The amount of hoops I had to jump through to get it to make a Nim install from the binary distribution including the MinGW download and install where enough to furnish a whole gymnastic school.
Then I had convince the installed choosenim proxy executables to actually use the custom choosenim dir set in the CI tests, so it would actually run the nim compiler and gcc that where just installed in that custom choosenim directory by the test. Turns out, you couldn't actually do that yet, because you would need the --chosenimDir command line option for that and the proxy executables would pass that option on to the proxied executables, who would of course error out because they don't recognise that argument.
So I had to add support for a CHOOSENIM_DIR environment variable, just to able to write the test properly. Well, that might come in handy anyway.
So, I first thought that, as I've mentioned above, that the root of the issue was not passing on the full path of the proxied executable from the proxyexe when using the new method of calling the proxied executable using execv:
https://github.com/SpotlightKid/choosenim/actions/runs/16211913011/job/45773537780?pr=4#step:5:213
Fixing that got rid of the error in the original report, but the MingW gcc still failed, this time in the linker:
https://github.com/SpotlightKid/choosenim/actions/runs/16212138680/job/45774147612?pr=4#step:5:197
So, I reverted back to using startProcess in the proxyexe on windows and that seems to have fixed the problem.
https://github.com/SpotlightKid/choosenim/actions/runs/16212303384/job/45774616630?pr=4#step:5:173
I'm currently out of ideas why the execv method doesn't work on windows. Since I'll be away for the weekend without access to a computer, I'll open a PR with the new test and fix/revert and the choosenim maintainers can decide what to do.