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

[Philipp Hausmann]

Interestingly enough, we have some of the same questions for the Agda
programming language. Currently, Agda doesn't really have any package
manager, so there are no backwards-compatibility problems with using Nix.

It would be really nice if we could use Nix as the one-and-only package
management solution for Agda. However, Nix doesn't support Windows,
which means we need a second fallback solution. This is rather
unpleasant, but not a show stopper.

For Agda, I'm currently leaning towards defining a simple package json
format and a very basic build tool and to build Nix support on top of
that. Kind of like the Haskell packages.

I'm certainly interested in how you're solving this problems and I will
keep an eye on it, maybe I can steal some of your work and use it for
Agda ;-)

Cheers, Philipp

> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160212/8df081e1/attachment-0001.bin