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

[Rok Garbas]

Hi,

While I don't work on any new language I do work with large sets of packages
which I have to keep stable and at the same time develop them.

What bothers me with in most programming languages and their package managers
is that there is no known-good-set of working together packages. Stackage (from
haskell world) is a nice example how I would envision if I would have a chance
to start from scratch. This is similar to your idea of `mtpkgs`.

I'd extend `mtpkgs` to a fixed revision of `nixpkgs`. `mtpkgs` would be
a collection of url+sha256, pointing to the default.nix in that tarball. This
way you get best of both worlds: stability and extensability via local
default.nix.

A release to `mtpkgs` would be a PR with new url+sha256 which you can test if
it builds before merging. If you structure `mtpkgs` you shouldn't see have any
merge conflicts. Ofcourse this could be done nicely with some tools build
around github/nix.

With introductions of `buildins.fetchTarball` this is made very easy to do.

What most package managers fail to deliver is the promise of letting you know
(as a author of a package) that your package is not working for everybody.
I think this is the most important things that some try to hide it and put it
on the shoulders of developers (eg. you should test that your package works
with everything), which is insane requirement. I think with Nix you can achieve
this while not hurting UX and ease of usage.

My 2 cents.


Quoting cds at corbinsimpson.com (2016-02-09 17:40:29)
> 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


--
Rok Garbas - http://www.garbas.si
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160209/30fef750/attachment.bin