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?
