Problem: No obvious way for users to generate a racket environment with arbitary packages

[clacke]

Python on Nix has a nice separation between packages on the one hand, and python environments with packages installed on the other hand. racket2nix builds an env output with every derivation.

As a user, I cannot easily just say "hey, give me a racket that has fractalide and also compiler-lib, so I can run raco test on it". With python it's as easy as nix-build -E 'with import <nixpkgs> {}; python.withPackages (pkgs: [pkgs.foo pkgs.bar]), super neat! Of course, that's cheating a bit because there's a python package catalog in there already. On the other hand, we kind of do too.

With racket2nix I have to do nix-build -E 'with import <racket2nix> {}; (buildRacket { package = "thepackage"; }).env. Not many more characters, but admittedly a bit clunky. And no way to create an environment with two unrelated packages present -- I'd have to synthesize a package that depends on them.

If we generate the racket environment explicitly, we could make package derivations slightly thinner and less involved -- maybe we could even keep circular dependencies in their own derivations, maybe we wouldn't run setup on them, just copy them in -- and we could make the racket environment a bit thicker than today's implied env output. E.g. we could symlink all the dependencies into one place and skip the enormous etc/racket/config.rktd.

Most of all this relates to #78. A racket with all the deps explicit and in one place could generate info-cache.rktd appropriately.

This kind of thinking might also make it easier to generate the environment without having to explicitly list all transitive dependencies in racketBuildInputs.

Part of this is solvable without doing much new, like #157 solves part of it, but I think looking at it from a new angle could help clear the interfaces up.

[clacke]

Some of the reasoning above is outdated (as one might hope after half a year more of working with and on the tools). My current work in building racket package derivations in general is about skipping the big config.rktd, just like mentioned above, but not by symlinking things in, but instead link-installing (raco pkg install --static-link) all transitive dependencies in each derivation. That means the information goes right into links.rktd without any indirection via directories (the current approach with huge links-search-files and pkgs-search-dirs) or symlinks (as discussed above), and, yes, it also goes into info-cache.rktd and should solve #78.

Preliminary results are promising. And the way I'm designing it is that the racket environment for each package is put together much like an environment for an arbitrary set of packages would be put together, so it should be easy to factor out and reuse to solve this withPackages issue too.

[jakeisnt]

Has there been any further progress on this?