Description
Is your feature request related to a problem? Please describe.
When I'm entering the nix repl
, I often like to set up a couple definitions for convenience before I start evaluating expressions, like this:
$ nix repl nixpkgs
Loading installable 'flake:nixpkgs#'...
Added 5 variables.
nix-repl> pkgs = legacyPackages.aarch64-darwin
nix-repl> hsPkgs = pkgs.haskell.packages.ghc96
Unfortunately, there's no way to configure this sort of behavior for nix repl
, and even if there was a setting like repl-default-bindings
it wouldn't account for the dynamism of the values that might be loaded.
Describe the solution you'd like
I would like a repl-startup-files
setting, which could default to a path like ~/.config/nix/repl.nix
. The file would contain a function of type AttrSet -> AttrSet
. nix repl
would call the file with the initial top-level variables as the first argument and replace the top-level variables with the resulting expression.
Then, the bindings I've added manually above could be added automatically like this:
vars: let
pkgs =
if vars ? legacyPackages.${builtins.currentSystem}
then vars.legacyPackages.${builtins.currentSystem}
else if vars ? packages.${builtins.currentSystem}
then vars.packages.${builtins.currentSystem}
else null;
hsPkgs =
if pkgs ? haskellPackages
then pkgs.haskellPackages
else null;
optionalAttrs = condition: attrs:
if condition
then attrs
else {};
in
vars
// (optionalAttrs (pkgs != null) {inherit pkgs;})
// (optionalAttrs (hsPkgs != null) {inherit hsPkgs;})
Perhaps we could also provide a global variable like __replSource
to indicate which flake or file is being loaded. Then, users could dynamically provide bindings for specific flakes. Alternatively, flakes could set nixConfig.extraReplStartupFiles
to check in project-specific bindings.
Describe alternatives you've considered
One alternative would be a repl-bindings
setting, which might look like this:
repl-bindings = pkgs=legacyPackages.${builtins.currentSystem} hsPkgs=legacyPackages.${builtins.currentSystem}.haskellPackages
I think this would be much clumsier to use and would introduce another unfortunate whitespace-sensitive DSL. The lack of newlines in configuration files would also make it much harder to keep the definitions organized neatly.
Priorities
Add 👍 to issues you find important.