Problem: Output is not composable

[clacke]

Every time we run racket2nix we get a self-contained nix expression, and the user can't do much with it, or rather to it.

#17 would make it output an attribute set instead, which is better, but still not good enough -- you can't override one package and have other packages depend on your override.

Solution: Support outputting an overlay.

I'm not even talking about just outputting a recursive function, and wrapping it in lib.makeExtensible. That's great, and we want that for the base catalog. No, I'm talking about the next layer of abstraction.

We can output a thin Nix expression and do zero lookup in package catalogs. No definition of mkRacketDerivation, no knowledge of where "rackunit-lib" or "pict-lib" is going to come from, just output a self: super: { "my-package" = self.mkRacketDerivation { pname = "my-package"; src = blah; racketBuildInputs = [ self."base" self."rackunit-lib" self."pict-lib" ]; }; } and that's the whole expression. You can do this from the info.rkt alone and rely on Someone Else to provide the greater package universe.

With #176 you could even have a {buildRacketOverlay}: buildRacketOverlay [ ./my-package ] be the whole Nix expression and not even bother with an info.rkt.

Benefits:

• No catalog generation in fractals
• Overridability everywhere
• Quicker buildRacket
• Allows us to not even generate a catalog.rktd, just need a nix expression full of self.mkRacketDerivation.

This supersedes #17 and #123.
This requires solving #24 and probably #158 (which in turn hopefully solves #78).

It'll be glorious. Biting into this in September. It may not even be much work, mostly the prerequisite issues have some unknowns.

[clacke]

When generating the catalog, we will have to take care of circular dependencies. For people creating their own derivations, just tell them not do do circular.