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

[cds at corbinsimpson.com]

> There are so many details to distributing software. Let me quickly take a
> try to dump my thoughts.
>
> Have a static metadata file that is well defined (has a specification with
> a version number of the format).
> If you pick JSON, be aware it doesn't allow comments by specification. If
> you add comments, most JSON parsers will break.

Sure. Honestly, there's not much that I'd expect a package to declare that
isn't already in a derivation: Petname, version, manifest, dependencies,
license... What else might there be?

> Having a static metadata file is important, as others might want to parse
> it - like anyone trying to figure something out about a package. You could
> also define a Nix expression that
> can be converted to a JSON and that leaves you the possibility of
> comments.
> But *make sure* the json is generated when the package is "distributed".

Monte's compiled format is machine-independent, so for us, "distributed"
means "in the local Nix store". We *do* intend to generate a small
JSON/etc. stub which contains information about the direct dependencies of
the package, so that our package loader can recurse on those dependencies.

As for what a Monte package looks like before it gets into the Nix store,
that's something that we never expect Nix to really handle. Our eventual
distribution method will probably be NDN, and Nix is not likely to ever
deal with that. (And that's fine.)

> Another thing to be careful is to think about dependencies as a DAG. No
> circular dependencies. Again, if you take Nix that's already handled.

Right.

> If you're going to use Nix, be sure to understand how Haskell works. It's
> far most sophisticated. A good overview is at
> https://www.youtube.com/watch?v=TDnZsBxqeBM&list=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy&index=4

The Haskell pipeline is indeed quite complex.

Unless we can't express versioned dependencies in Nix, I'm not sure what
we should be taking away from the Haskell situation. We just don't have
the same problems.

> The big downside of using Nix is that people have to use it. If it's not
> going to be dead simple, you'll hear swear words :) And that against
> brings
> back to my point one - have a good specification of packaging metadata.
> If you are willing to help us improve that barrier, that's amazing since
> we're be all better of.

I humbly submit that people put up with npm, pip, and cpan on a daily
basis; I do not feel bad about asking people to use Nix in the specific
case where they want to develop Monte packages.

Actually, let me say that a different way: What doesn't Nix do, that we
might want it to do? What did Nix do wrong that we could do right? I
thought about this for a bit but couldn't think of anything that is really
bad about Nix other than that it doesn't come installed by default on
Ubuntu and it requires folks to learn Yet Another Build Script DSL.