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. 

Reply via email to