[Nix-dev] Using Nix as the preferred package manager for a new language

[cds at corbinsimpson.com]

> I think the idea is exciting but difficult. Some notes / questions:
>
> 1/ Nix stores its data in /nix/store - is your package manager OK with
> root
> access? There are ways around that, e.g. using --with-store-dir but see
> [1].

*Nix* is our ideal package manager. We don't have any other package
manager. We are not retrofitting some ecosystem to Nix; we hope to build
our ecosystem on Nix.

We currently use standard Nix tools to manipulate our environments. I have
an IRC bot written in Monte; its deployment looks like:
$ nix-channel --update # Fetch the latest builds from our Hydra
$ nix-env -i airbrus   # Update the bot to the newest version
$ airbrus ...          # Run the bot!

Our current foray is mostly focused around how to set up development
environments using Nix, and what kinds of files and conventions define a
Monte package.

> 2/ Do you want semver versioning or some form of always-follow-HEAD with
> stabilization branches like e.g. nixos or stackage LTS do?

We haven't decided.

Semver's "nice". I've used it in the Haskell ecosystem. It works as long
as everybody plays nice. Also Haskell's linkage restrictions ("Cabal
hell") mean that while semver might be *correct* semantically, it's also a
pain to manage.

Both Allen and I are long-time Twisted folk, and Twisted uses semver but
its major number always reflects the current Gregorian calendar year. This
enables us to see at a glance how old a system is when people come asking
for help. "Help, my server doesn't work and I'm using Twisted 8" instantly
tells us that they're on an eight-year-old library version. This is
technically incorrect semver since the API doesn't break anually, but
nobody minds.

Go's YOLO non-versioning is interesting. Gophers, like Haskellers,
typically only care about whether their program compiles and superficially
appears to work. We could take this a step further in Monte, since we have
builtin testing facilities, and allow the "latest" version of a package to
be added to an environment as long as it passes all of its unit tests. We
are sheepish about this path because it requires everybody in the
ecosystem to write good tests, and (let's be honest here) nearly nobody
writes enough tests.

An idea from Haskell that we recently floated was the idea of the "Monte
Platform": Just like the Haskell Platform, we bless a certain set of
libraries at a certain version. This doesn't solve every problem, but
definitely being able to incant $(nix-env -i monte-platform) could improve
our new-user story.

> 3/ Will you ever bind to c libraries like postgresql?

We don't intend to produce any Monte runtime which provides a C FFI. I'm
sure that somebody will do it eventually, but it probably won't have our
blessing.

Of course, if you have a hypothetical Monte Web application, and you want
to use Pg as your database, then your Nix expression for your application
might include a Pg dependency, but that's different.

> If you can fall back on binaries from your underlying system then maybe 1
> isn't a problem - at the cost of reproducibility.
>
> Personally I think I'd follow Domen's advice of machine readable metadata
> and convert those into one big nix-expression on the fly before running
> e.g. nix-build.
> There are already several good examples for packaging *all* libraries for
> an ecosystem from metadata (Peter's excellent Haskell work, Gleb's hex
> packages, ...).

To reiterate an earlier point: There's nothing preventing us from using
nixpkgs and putting all of our Monte package descriptions into nixpkgs.
It's just not desirable; Monte package authors shouldn't have to wait for
nixpkgs PRs when they are publishing new Monte packages.