Nim has very few dependencies. It depends on no other ports on BSDs & 
[Gentoo](https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/nim/nim-0.16.0.ebuild),
 because the base system would always include certain minimum things. Nim's 
Debian port depends on "libc6(>=2.14)" and "libssl1.0.2". `rpm -qpR` on 
openSUSE's package [lists other things](http://pastebin.com/raw/MBZJGAxP).

It would be good to clarify exactly what Nim needs: **an official dependencies 
list**, including what minimum version, and what are the consequences of not 
having it. It would also be good to list optional things for Gentoo USE flags 
and make config.

If dependencies aren't an issue, it would be pretty easy to install Nim 
binaries with one 
[txz](https://en.wikipedia.org/wiki/Tar_\(computing\)#Suffixes_for_compressed_files)
 file per OS * CPU architecture combination. The main downside of that is the 
user won't be notified about updates.

> Here's an aarch64 (ARM64) build of mine:

It is a security risk for anyone to use binaries (or source code) that don't 
come from an official authority. This should either be the core Nim project 
team or the OS/distro package managers (which may delegate specific packages to 
specific volunteers, but with some degree of accountability).

I think the priorities of this effort should be to:

  * (1) Come up with a list of existing official packages by existing OS/distro 
package managers. It is better to have people install that way, so they get 
easy automatic updates, but only if the package manager keeps the Nim version 
up to date.
  * (2) Come up with an _automatable_ way of compiling Nim (including nimble, 
etc) txz's for many OSes and architectures. This could involve something like 
qemu or a cloud service like EC2. I've been looking into this, but the official 
Nim project binaries builds should be overseen by the core team.
  * (3) Create a widget for the download page where the user selects OS, 
distro, and architecture, and then gets instructions for the various ways (in 
order of what is recommended) of installing Nim: distro package, untaring our 
package, or building from source. I don't see why the last option should ever 
be mandatory.
  * (4) Nag the OS package managers that fall short to update / improve their 
packages based on our txz example and Nim's official dependencies list. We 
should also ask them to include nimble, because one of the main benefits of 
this effort is to ease deployment of software that is written in Nim.


Reply via email to