Installation on 64-bit Windows
For those finding this thread useful at the end of 2019, here is how I solved my issues with Nim on Windows. Just use `cmd.exe`. When Nim executes `vcvarsall.bat` from PowerShell, it runs and exits without errors. However, any `PATH` modifications do not persist when Command Prompt exits.
Re: Installation on 64-bit Windows
I've managed to find a link I knew I had in some folder. Now, no one specified if this solution had to be FOSS or could be commercial, so don't take it the wrong way if I'm posting a link to a commercial software: [http://www.deploymaster.com](http://www.deploymaster.com)/ I remember that I had a very good impression of this tool, and its developers are known for some other very well known software tools. Now, if the issue is making life easier for Nim maintainers, and what is needed is just a tool to create and maintain good Windows installers without headaches, and there are no problems regarding using a non FOSS software, I would be happy to sustain Nim and contribute buying a license for this app for the maintainer of Nim setup generator (if I've understood correctly, that would be @Araq). Right now its a diffcult moment for me, and I can't go to the length of covering the full price (€80), but I could cover a third of it and I'd be happy to. Of course, this could be a temporary solution, until a Nim-based setup manager will be ready. But the priority being right now to reach Nim 1.0, using this tool could provide some respite and lesse headches. Also, I'm rather confident that Nim being a FOSS project, we could expect some discount on this product. Worth asking. (of course, assuming it suits the needs of the maintainers)
Re: Installation on 64-bit Windows
I totally agree with keeping the number of official ways to install Nim to a minimum. And I also believe that unofficial solutions might be detrimental in the long run (for example, the unmaintained Choco Nim package didn't bring much good to those who installed through it). @dom96 wrote: > Over time this [setup] wizard has become more and more complex, NSIS and Inno > setup are simply too much of a PITA to maintain properly so I'm not surprised > that Araq wants to get rid of it. [...] > I would really love to write a > custom setup generator for Windows in Nim. This may even be a killer feature > for Nim because the current solutions are just plain crap. and @Varriount: > The old installer used NSIS, which is a headache to deal with (the installer > is built using the NSIS language, which closely resembles assembly and a > declarative language). > > Anyway, does anyone know some alternative that we might try out? I know that > we've tried WiX (too much XML), NSIS (too much assembly), and Inno (way, way > too much programming needed). Any others? So (just trying to understand and see if I could help here), the problem has to do with the software used to build the installers, right? I could so some research in this and see if something more user friendly could be used, taking in consideration that new features/components should be easily integrated. Dom's idea of creating a setup generator in Nim is far the coolest. Surely, it will add maintainance of the generator itself, but sounds worth it since it would taylored to Nim's needs (and, of course, a reason of pride for Nim itself). > The alternative ways to install Nim might grow a new feature (e.g. choose > between Aporia and VS Code Plugin) I personally think that Aporia should have a separate setup. True, for the first-timer it's nice to have a single setup, but they are two separate products and they might update at different intervals. If we are speaking of an installer "the Windows way" it should then also provide an uninstaller, and the catch might be that to uninstall just Aporia you end up uninstalling Nim or, worst, the manually overwritten files (in one or the other) get busted because of an update that affects both.
Re: Installation on 64-bit Windows
> But this is true for any solution, whether Nim script, Chocolatey, or else! Yes, that's an argument for keeping the number of "official" ways to do something to a minimum, not an argument against Chocolatey in particular. > As I wrote, I was happy to contribute to the first "original" PowerShell > script (note the singular), and my proposal was centered around the idea that > the Choco package should be automated and self-update with new Nim releases, > requiring no further scripting. Yes but the work starts after the initial coding phase. It's not about replacing 0.16.0 with $version and have this script generated, that's indeed easy enough. It's about _maintaining_ this in the longer run. Issues might be reported, they need to be handled. The alternative ways to install Nim might grow a new feature (e.g. choose between Aporia and VS Code Plugin) and the Chocolatey package should support that too then. Also you have misunderstood me in various ways. I will accept such a PR, it's just that I am really skeptical.
Re: Installation on 64-bit Windows
I only partly agree with some of your points, though. True, Chocolatey is not part of Windows, but it was the first attempt (that I know of) of creating some packages manager for Windows, like apt-get on Linux, and similar. So the statement: > The main feature of Windows is that software can be installed without much > trouble. is true only for software that comes with an installer and has some update mechanism. But I think that Chocolatey success is also due to the fact that it provides a centralized place to check if installed software packages are up-to-date (again, on Linux distros like Ubuntu you have this feature with package manager frontend). As far as I know, Microsoft has no plans (and never had) to implement any third party packages manager (they only invest in their own products). True, the proposed solution will mainly help Chocolatey users, and **will** introduce a new burden on Nim developers. But, if I understood correctly this thread, the issue rotates around the recent news that Nim might no longer ship as a Windows installer in the nearby future, only as a ZIP archive. An there was mentioning of the fact that developers are currently struggling maintaining the setup version (NSIS et als). So, really you should contextualize better my proposal. > But I don't want to write PowerShell scripts. As I wrote, I was happy to contribute to the first "original" PowerShell script (note the singular), and my proposal was centered around the idea that the Choco package should be automated and self-update with new Nim releases, requiring no further scripting. > Every officially sanctioned way to install Nim needs to be tested, for every > single release. But this is true for _any_ solution, whether Nim script, Chocolatey, or else! > Right now we support: > > * installation via the installer.exe. Again, the question ensued from the official announcement that has been placed along the latest release of Nim: > Note that these installers have some known issues and so will unlikely to be > provided further in the future So, ok --- Chocolatey being a big "No!No!" for some reason I can't phatom ---, we get back to the point of the future of Nim packages for Windows. > ... I'd rather write Nim programs instead. Makes a lot of sense (I'm afraid I can't contribute here though), I just didn't know there were plans in that direction. All I've read on the download page is that installers might soon stop being released, and that the official guidelines are: > We now encourage you to install via the provided zipfiles Again, I don't want to insist but I must: this whole thread started from end users' considerations that presently setting up Nim through zip archive does pose some complications (to _real_ and _unreal_ programmers alike, apparently). I can't avoid thinking that my proposal was dismissed a bit too hastly. I too, like @mindplay have a some programming experience behind (35 years), which if it taught me anything at all that would be that computing is a wide field and there are paths which one might simply never cross if he works in a given field "X" rather than fileds "Y" and "Z". I've started only recently to use Linux software that has been ported to Windows, and I don't have problems admiting that sometimes seting up the right working environment can be puzzling. And I don't think it has anything to do with being _real_ or _bogus_/_wannabies_ programmers --- often it has to do with lack of field-specific experience, or lack of well written documentation. Anyhow ... it's fine. I'll just go for the zip archives and whatever Nim shall offer in the future — frankly, I don't have all these problems seting up Nim from a zip archive. I have more difficulties handling scattered updates (Chocolatey took away 1/2 of the burden through a single GUI that notifies me of new updates for dozens of packages) — but of course, this is _me_, my likes and dislikes, my problems and views.
Re: Installation on 64-bit Windows
> What do you say, does it make sense? Somewhat. I don't mind PRs so that a Chocolatey script becomes part of "core" Nim, but that does not solve anything for us core devs, in fact, it creates more work for us. I certainly don't want the installation to depend on Chocolatey, it's not an official part of Windows, most likely doesn't work on Windows XP etc etc, so the old ways to install Nim would continue to exist. The main feature of Windows is that software can be installed without much trouble. > As you can see it's not a great deal of code. Of course, this one relies on > Nim setup, but Chocolatey can handle unpacking archives and do all sorts of > operations with it — PowerShell does a good job at setting env-vars, > registering apps, and anything else Windows-related. But I don't want to write PowerShell scripts. Been there, done that, thanks I'd rather write Nim programs instead. **Every officially sanctioned way to install Nim needs to be tested, for every single release.** Right now we support: * installation from tar.xz. * installation from the zips. * installation via the installer.exe. * installation from github. You think we can add "installation via Chocolatey" to this list and it would help us. No, it wouldn't. It would help _you_ as a user of Chocolatey.
Re: Installation on 64-bit Windows
As I've posted elsewhere ([http://forum.nim-lang.org/t/2679#16589)](http://forum.nim-lang.org/t/2679#16589\)), I think that a good solution would be to use Chocolatey. There is already a Nim Choco package, but it's way unmaintained: [https://chocolatey.org/packages/nim](https://chocolatey.org/packages/nim) The advantages of Cholocolatey are that its already a well-established app for installing updating all sort of packages that don't come with an installer, and offer the final user a single interfact (ChocoGUI) from which to update all packages. I use it to update Ruby, Node, Go, and other langs, which is much better than having to manually check via the browser if a new release is available, and then go through the whole setup process. Since Choco packages are executed silently, there is no clicking YES, YES, YES ... YES at each update to confirm existing settings. But his also means that a Nim package would have to be thought over carefully, for example: I think tha Aporia IDE and MinGW shouldn't be in the main Nim package because in silent installation the user is not given a choice over these. Maybe multiple Nim packages could be created: Nim 32bit, Nim 64bit, Aporia, and even a Nim package for installing MinGW or TDM-GCC --- which would solve the main issue that started this thread, ie: offer users help on setting up a GCC environment on Windows. I believe that we need an official Nim packages on Chocoloatey, to avoid having yet another umaintained package. Also, since Choco packages are just Powershell scripts, usually hosted on GitHub, the whole process could be integrated into Nim's release cycle: when a new version of Nim is released, some script could automatically edit the strings in the choco-package to the new release number and download link, and push a commit to GitHub and (I guess) even update the package on Choco website. I am convinced that Choco is the easiest solution to maintain, and since it is normal that a software has different choco packages, it would allow to create different setup scripts, covering all possibile needs.
Re: Installation on 64-bit Windows
I've downloaded the old Nim Chocolatey package (this on isn't on GitHub), unpacked it and peeked inside it. This is the core of the package (chocolateyInstall.ps1 script) $packageName = 'nim' $version = '0.11.2' $fileType = 'exe' $installArgs = '/S' $url = 'http://nim-lang.org/download/nim-0.11.2_x32.exe' $url64 = 'http://nim-lang.org/download/nim-0.11.2_x64.exe' Install-ChocolateyPackage $packageName $fileType $installArgs $url $url64 As you can see it's not a great deal of code. Of course, this one relies on Nim setup, but Chocolatey can handle unpacking archives and do all sorts of operations with it — PowerShell does a good job at setting env-vars, registering apps, and anything else Windows-related. Creating a template and implement some preprocessor that updates the strings for Nim version, the various download URL, ecc., should be a piece of cake. Using GitHub to host the Choco Nim package might also make sense, because GitHub API could be used to further automate the process of updating the package(s). But in my opinion it only makes sense if it's going to be an officially maintained package, strictly integrated into the release chain. I'm no Choco/PowerShell expert, but I've enough experience on Windows OS to say I could look into Chocolatey documentation and contribute to create and test a base Nim package that installs Nim from archives instead of an installer. But all the rest -- intergrating it into the release chain, implement a template system to autoupdate the packages, ecc, -- would have to be taken on by someone from Nim's dev team. Also, most important of all, the registration of such a Nim package on Chocolatey (and its correspective GitHub repo) would have to taken on from dev team. What do you say, does it make sense?
Re: Installation on 64-bit Windows
> A Nim script to install Nim on a machine which doesn't have Nim on it? Well, a Nim program then - compiled executables can stand alone, right?
Re: Installation on 64-bit Windows
> But rather than using a nimscript, why not just a simple installer written in > Nim? That would have full access to network libraries and anything else it > needs. Yes, and that's why we have the `finish` tool. That should get a download feature, problem solved.
Re: Installation on 64-bit Windows
The zip file can contain any additional tools needed, such as a downloader. But rather than using a nimscript, why not just a simple installer written in Nim? That would have full access to network libraries and anything else it needs.
Re: Installation on 64-bit Windows
The big problem with a self-extracting executable is that we need the capability to download extra components - namely MinGW. Bundling MinGW with all installs dramatically increases download size, not to mention that if the MinGW component needs to be updated, so does the rest of the installer.
Re: Installation on 64-bit Windows
> I'd love to see how that worked ... You need a nim.exe but you don't need anything installed. You can create a self-extracting zip file (called installnim.exe, or setupnim.exe, etc.) containing the nim executable, the script, and anything else needed. You can set up the self-extractor to run a command after extracting; see, e.g., [http://stackoverflow.com/questions/27904532/how-do-i-make-a-self-extract-and-running-installer](http://stackoverflow.com/questions/27904532/how-do-i-make-a-self-extract-and-running-installer)
Re: Installation on 64-bit Windows
A Nim script to install Nim on a machine which doesn't have Nim on it? I'd love to see how that worked ...
Re: Installation on 64-bit Windows
> there was no offense implied There was no offence taken really, I took it in good humor. I should have clarified "Ouch, thanks" with a > Any others? Why not a Nim script? Tools etc. are installed with Nim scripts. Seems "at hand"?
Re: Installation on 64-bit Windows
Anyway, does anyone know some alternative that we might try out? I know that we've tried WiX (too much XML), NSIS (too much assembly), and Inno (way, way too much programming needed). Any others?
Re: Installation on 64-bit Windows
> I have yet to find a single programmer on Windows that acts this way > >> Ouch, thanks. Sorry, but you yourself _did not_ act this way (!), you tried multiple things (and even reported your findings back), so there was no offense implied. Should have stated this more clearly, sorry.
Re: Installation on 64-bit Windows
@mindplay I suspect the main reason for araq's vehemence is not malicious, but maintenance fatigue. The old installer used [NSIS](http://nsis.sourceforge.net/Main_Page), which is a headache to deal with (the installer is built using the NSIS language, which closely resembles assembly and a [declarative language](http://nsis.sourceforge.net/Sample_installation_script_for_an_application))
Re: Installation on 64-bit Windows
I've always considered Nim's windows support to be the best out there. One of the reasons for this was the setup wizard. Over time this wizard has become more and more complex, NSIS and Inno setup are simply too much of a PITA to maintain properly so I'm not surprised that Araq wants to get rid of it. **@Araq** I think you're wrong, setup.exe is an expectation for all software on Windows. A standalone archive is a nice bonus, not a replacement! I also can't imagine what could be easier than setup.exe. I would really love to write a custom setup generator for Windows in Nim. This may even be a killer feature for Nim because the current solutions are just plain crap.
Re: Installation on 64-bit Windows
> I have yet to find a single programmer on Windows that acts this way Ouch, thanks. For the record, I have been programming for 30 years, professionally since the mid-80s - I can program in around a dozen languages, and have built some fairly big and complex systems over the years, so I do consider myself a _programmer_. But I grew up on languages like Pascal, Delphi, Modula-2, JavaScript, ActionScript and various Basic variants, and consequently learned from the start to count on languages and development-tools that work "out of the box", where you can focus on solving problems, rather than getting distracted by a lot of environment issues and manual setup. Growing up on said languages, I also never had any love or interest for languages like C or C++, where you have to get distracted by things like memory management and other low-level cruft. I think Nim holds a lot of promise for programmers like me - it appears to be a language with multiple "levels", kind of like Scala or Rust, where you can choose to program like I would program in Java or C#, where I don't have to get distracted by things like memory-management or threading issue, but where someone else who needs or wants to can go to more low-level features and manage memory etc. if they need to. Anyhow, whether it's a "setup.exe" or step-by-step instructions, for "idiots" like me who just want to try out the language and use it to solve problems, things surely could be improved. It shouldn't take hours for someone like me to get a working language and editor installation set up. Nim surely appeals to more "hardcore" programmers because of it's depth, but I think you have potentially a much larger audience among people who use more "humble" languages like PHP, JavaScript, Ruby, Go, etc. - all languages that even lazy Windows users can more or less click to install and dive in. I think Nim has the potential to compete with all of those. If we can figure out how to install it, haha
Re: Installation on 64-bit Windows
The new 0.16.0 release has a better `finish.exe`, please try it and report problems here. > In fact, most Windows users will give up if you don't provide a working > "setup.exe", because that's what we're used to. I have yet to find a single _programmer_ on Windows that acts this way. You're surely not the first who claims this though. IMHO this only applies to Windows end users. Many programmers do not even want a setup.exe, they want a zip because that's guaranteed to work from USB sticks etc.
Re: Installation on 64-bit Windows
It seems too that tdm-gcc is the most convienent way in windows to get a compiler but it does not seem to like vulkan libs (trouble linking). And you have to deal with winpthreads licence, but you get a working compiler easier it still works for opengl for instance. but i switched too linux mint to play with vulkan and nim.
Installation on 64-bit Windows
On the download page, it says that the Windows installers "have some known issues and so will unlikely to be provided further in the future" \- and that "We now encourage you to install via the provided zipfiles", so I wanted to do that. So I decided to start fresh and removed my previous installation. There's a link to mingw-w64.org somewhere else on the page, but I could find no real instructions or recommendations on how or where to get a working GCC installation - especially not on their website, which lists dozens of distributions with different versions etc. and still no recommendation on which one to get. Somewhere else on the page, it says "GCC is recommended on Linux and Clang on Mac. The Windows installers above already includes a C compiler" \- but the Windows installers aren't recommended, so that's not very helpful. I finally decided on MSYS2, and found instructions on stackoverflow for installation: [http://stackoverflow.com/a/30071634/283851](http://stackoverflow.com/a/30071634/283851) I've never used MSYS2 - to be honest, I'm not completely sure I even understand what it is, or why I had to install it. It's like Bash for Windows, kind of like Git Bash? I also had to figure out where it actually installs the GCC binary, because it doesn't add the folder to the system path, so the GCC command could not be run from a normal Windows shell. Well, I finally have it working, I think - at least, typing "gcc -v" outputs "gcc version 6.2.0 (Rev2, Built by MSYS2 project)", so far so good, right? Unzipped nim and ran "finish.exe", and this is where I'm stuck - it says "No compatible MingW candidates found in the standard locations". However, if I try to compile something, it seems to work?? I type "nim c koch.nim" for example, it compiles, and emits a "koch.exe". Both "install_tools.nims" and "install_nimble.nims" seemed to fully compile and execute with the "nim e" command, so I'm not sure what the error-message from "finish.exe" is even about. Do I need to do anything else, or do I have a working setup now? If you want more Windows users to try nim, I really think you need to provide more complete installation instructions - it took me hours to get a working setup. You seem to assume that most users have a working C compiler setup already, which most Windows users likely do not. In fact, most Windows users will give up if you don't provide a working "setup.exe", because that's what we're used to. Most of us don't have or use (or want) command-line package managers - it's not really "a thing" on Windows. And yes, we're pampered that way - but most successful languages do ship with a "setup.exe" for Windows users, so that's just what we're used to. Either way, if you want us to install not only nim but it's dependencies manually, please do try to provide complete instructions.
