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

[Игорь Пашев]

If you don't want a new package manager, why a new language?
10 февр. 2016 г. 0:40 пользователь <cds at corbinsimpson.com> написал:

> 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.
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160211/d15a2134/attachment.html