[Nix-dev] Using Nix as the preferred package manager for a new language
cds at corbinsimpson.com
cds at corbinsimpson.com
Tue Feb 9 17:40:29 CET 2016
Hi! I've tried to start this discussion a couple times on IRC, but it
hasn't really gotten attention, so:
I'm one of the developers of Monte, a new programming language. We don't
want to write a package manager, because package managers are hard. (Also
we've been watching npm happen for the past few years.) So we plan to use
Nix. However, we've got some requirements for our package layout, and we
haven't seen anybody else do all of the things we want at once. Here's
what we're thinking:
* Monte packages shouldn't live in nixpkgs. We use standalone Nix
expressions to build stuff like our runtime, and it makes development very
speedy since we do not have to round-trip our Nix changes through nixpkgs.
We also want to keep Nix expressions for packages close to the packages
themselves (see next point.) Perhaps when our ecosystem has developed
more, we can revisit this.
* Monte packages should bundle their own Nix expressions. Our reasoning is:
** Suppose that we have some "mtpkgs" tree, which is like nixpkgs but only
contains a Nix expression for building some or all of the Monte runtime
and packages. However, now we've decoupled the description of the packages
from the packages themselves, which makes maintaining the package harder,
since changes to the package require a corresponding change to mtpkgs. We
didn't gain anything over just using nixpkgs!
** Okay, so instead we make a JSON (or whatever) description of each
package, and ship that with the package. Then, we interpret that
description as a Nix expression, and do Nix things as usual. Except that
this doesn't work, because now the JSON description is a new package
manager format! We didn't want that.
** So it seems like packages should ship with a Nix expression.
* Packages should be easy to cargo-cult. This might sound weird, but my
experience in other ecosystems (especially Python and Perl) has taught me
that most package descriptions are cargo-culted from other similar
packages. We should have a very custom Nix derivation-producing function
which turns a minimal Nix expression into a full Monte package
description.
So with that in mind, here's where we currently are. We have a runtime and
some packages. There's a terrible terrible Nix function that generates
derivations (
https://github.com/monte-language/typhon/blob/master/default.nix#L11-L34
). An example usage is (
https://github.com/monte-language/mt-rational/blob/master/default.nix ).
As you can see, our derivations are not especially good. We don't have a
good way to locate a runtime so that we can call ``montePackage`` easily.
Once our packages start depending on other Monte packages, the problem
will only be worse. We also have this indirect dependency on nixpkgs for
library stuff, which is worse than a direct dependency or no dependency at
all.
We're seeking any advice on how to make this situation better. As far as
we can tell, nobody else has tried to make Nix their first-class preferred
package management solution for their language, so we are blazing trails
here.
Thanks!
~ C.
More information about the nix-dev
mailing list