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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
