enterShell/script/subcommand phases

[bobvanderlinden]

Currently I'm running into limitations of scripts and enterShell when extending devenv with modules.

For instance, I'd like to add some 'assertions' to enterShell from a module. Assertions are runtime checks like:

• Does ~/.npmrc have the authorization tokens?
• Are the tokens valid?
• Does ~/.m2/settings.xml refer to the local repository that the project is presuming to use?
• Does /etc/hosts contain the entry that the project presumes?
• Does the hardware support CUDA?

I'd also like to automatically run bundle.

I also want to show a welcome message explaining some of the standard commands for the project (general setup, db setup, run the application, run the tests).

The order of these actions is important. Assertions must be run first. Welcome message must come last.

When adding these to enterShell it'll be added in the order that the modules are loaded, which is quite error-prone. In addition, when the project devenv.nix defines enterShell, those lines will always come last.

When adding these to a (setup) script using scripts.setup.exec it'll not be possible because the type is str, which doesn't append automatically like lines does.

I'm thinking of some kind of phases:

script.setup.phases = mkBefore [ "assertion" ];
script.setup.phase.assertion = ''
  if ! test -f ~/.npmrc; then echo "No npmrc!"; exit 1; fi
'';

scripts.setup.phases = mkAfter [ "welcome" ];
script.setup.phase.welcome = ''
  echo Hello!
'';

script.setup.phases = [ "bundle" ];
script.setup.phase.bundle = ''
  bundle
'';

which should result in

test -f ~/.npmrc
bundle
echo Hello!

Is some form of this useful?
Are there others ways of tackling the problem?

[domenkozar]

I'll think about this one a bit more, since it needs to be carefully crafted.

[bobvanderlinden]

The proposed solution is mostly adopted from the mkDerivation phases (unpack, build, configure, install). There it works alright. I'm interested in any other solutions.

[adrian-gierakowski]

In devshell there is a mechanism to declare dependencies between startup commands.

A config which defines greet and check startup steps, where greet should be executed after check could look like this:

{
  devshell.startup = {
    check = { text = "echo checking stuff..."; };
    greet = {
      deps = ["check"];
      text = "echo hello there!";
    };
  };
}

See the option definition here and here

The setup commands (which are bash snippets) are ordered using textClosureMap function from nixpkgs.

startup is of type attrsOf submodule so arbitrarily named phases could be added

I'd be happy to port this to devenv. @domenkozar I guess this would need to be added as an additional top-level option as we'd want enterShell to remain as it is for backwards compatibility?

[adrian-gierakowski]

I'd say all the included module should define their enterShell script in the above way, so that for example, one could ensure that ones custom startup command executes after files have been generated.

[adrian-gierakowski]

Additionally, we could add an enable option (true by default in most cases) to the startup submodule to allow selectively disabling of different startup scripts. Then, for example, if the files module added it's startup command via startup.files, the use could decide if they wanted the files created when entering the shell or not, by togging startup.files.enable.