[Feature]: Custom ENV variable definitions

[alejandrosame]

What's missing?

I found myself needing to define ENV variables when creating a custom kernel. The current function signature (see below) does not allow to pass ENV definitions to the available kernel.

https://github.com/tweag/jupyterWith/blob/8cb4db9bec9586ceb1269d33507fdaa31d8e358a/kernels/available/python/default.nix#L1-L22

Possible solution

The Rust available kernel already defines more than a PATH environment variable:

https://github.com/tweag/jupyterWith/blob/8cb4db9bec9586ceb1269d33507fdaa31d8e358a/kernels/available/rust/default.nix#L39-L40

I suggest that a new attribute extraEnvVars be introduced:

{ ... 
, extraEnvVars = [
   { VAR1 = VALUE1; }
   { VAR2 = VALUE2; }
  ]
, ...
} : 
{ ... }

The reason to format it as as a list of sets is:

• to preserve the order in which they are defined. The builtins primitives attrNames and attrValues reorder names alphabetically.
• so later jupyterWith could easily check for "protected" variables (e.g. PATH and RUST_SRC_PATH in the previous code snippet) that would need special handling (e.g. either drop or combine ).

Alternatives

No response

Additional context

No response

[djacu]

Hey @alejandrosame

Thanks for submitting this. It is a really good idea!
There is a big PR @garbas and I have been working on for the last two months and it is going to change a lot of things.
I'll take a look at implementing this after the PR is merged.

I appreciate the thoughtfulness you put into the solution. I had thought about implementing a function to do something like this previously because some of the kernels require multiple environment variables being set. Like you mentioned above.

What about an interface like this?

extraEnvVars = {
  arg0 = [
   { VAR1 = VALUE1; }
   { VAR2 = VALUE2; }
  ];
  arg1 = [
   { VAR3 = VALUE3; }
   { VAR4 = VALUE4; }
  ];
};

Where arg0 and arg1 would be the different flags that you can use in makeWrapper.

So you could use it like

extraEnvVars = {
  set = [
    { PATH = /foo; }
    { RUST_PATH = /bar; }
  ];
  run = [
    ...
  ];
};

And then things under set would use the --set flag and things under run would use the --run flag. Maybe that is needlessly complicated, and all we need is set.

[GTrunSec]

closes by #524