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

[Roger Qiu]

There's some work on Nix on Windows:

* https://nixos.org/wiki/Nix_on_Windows
* https://ternaris.com/lab/nix-on-windows.html

On 13/02/2016 12:01 AM, Philipp Hausmann wrote:
> 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.
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

-- 
Founder of Matrix AI
https://matrix.ai/
+61420925975

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160215/d4467765/attachment.html