Configure the initial shell.nix lorri init creates

[doronbehar]

Feature description

Every time I run lorri init, I edit this:

let
  pkgs = import <nixpkgs> {};
in
pkgs.mkShell {
  buildInputs = [
    pkgs.hello
  ];
}

To become:

with import <nixpkgs> {};
pkgs.mkShell {
  buildInputs = [
    hello
  ];
}

It would have been awesome if lorri would have read a skeleton shell.nix that would be used as the starting point, instead of the default.

Target users

Everyone.

Thanks for creating lorri BTW, it's super useful and comfortable never the less.

[Profpatsch]

Hm, I personally don’t think with pkgs is a good pattern to follow. (and with in general should be banned from nix for the most part).

It would have been awesome if there lorri would have read a skeleton shell.nix that would be used as the starting point, instead of the default.

What do you mean by that?

[doronbehar]

Hm, I personally don’t think with pkgs is a good pattern to follow. (and with in general should be banned from nix for the most part).

My main use of lorri is for quick and dirty shell.nix enabling me to compile / run a program from source to debug stuff for Nixpkgs' contributions. Hence, most of the times I don't care much for the quality of my shell.nix, I just want the environment variables to be set for direnv in order to get me going.

It would have been awesome if there lorri would have read a skeleton shell.nix that would be used as the starting point, instead of the default.

What do you mean by that?

What I imagine, is that if there's a file located at say: ~/.config/lorri/skeleton-shell.nix, it'll be used when lorri init creates the initial shell.nix. So say I put in ~/.config/lorri/skeleton-shell.nix the following contents:

with import <nixpkgs> {};
pkgs.mkShell {
  buildInputs = [
    pkg-config
  ];
}

When I'll run lorri init, it'll practically run cp ~/.config/lorri/skeleton-shell.nix shell.nix and hence the starting point of my shell.nix will be a little bit easier to edit. Here's another usecase:

A lorri user is using it exclusively for python development. Maybe all of their shell.nix files are based on:

let
  pkgs = import <nixpkgs> {};
in
pkgs.mkShell {
  buildInputs = with python3.pkgs; [
    requests
    setuptools
  ];
}

This feature will enable them to put exactly this content into their skeleton-shell.nix and they'll be able to add python packages easily right from the start, without the need to change this:

let
  pkgs = import <nixpkgs> {};
in
pkgs.mkShell {
  buildInputs = [
    pkgs.hello
  ];
}

Into this:

let
  pkgs = import <nixpkgs> {};
in
pkgs.mkShell {
  buildInputs = with python3.pkgs; [
    requests
    setuptools
  ];
}

After every lorri init invocation.

I understand that these shell.nix examples are written using "bad practices" but never the less I think it's legitimate for a user to have a choice on how their initial shell.nix should look like.

[kaleocheng]

Looking forward to such a feature too. In my case, I use lorri to setup the development env which includes lint tool/runtime/LSP. usually, I work on different projects with Python 2/Python 3/Node. when I jump to a new python project, I always need to edit the shell.nix to

let
  pkgs = import <nixpkgs> {};
in
pkgs.mkShell {
  buildInputs = with pkgs; [
    python3Packages.jedi
    python3Packages.yapf
    python3Packages.ipdb
    bashInteractive
  ];
  shellHook = ''
    unset SOURCE_DATE_EPOCH
  '';
}

and for a Node project, I need to edit it to

let
  pkgs = import <nixpkgs> {};
in
pkgs.mkShell {
  buildInputs = [
    pkgs.nodejs-10_x
    pkgs.bashInteractive
  ];
}

that would be great if I can specify which shell.nix file to use for lorri init

maybe something like:

# search for ~/.lorri/templates/python3/shell.nix
$ lorri init python3

# search for ~/.lorri/templates/node/shell.nix
$ lorri init node

[Profpatsch]

I’m torn on whether such a templating system a feature that should go into lorri or a separate project.

On Thu, May 21, 2020 at 12:25 PM Kaleo [email protected] wrote:

Looking forward to such a feature too. In my case, I use lorri to setup the development env which includes lint tool/runtime/LSP. usually, I work on different projects with Python 2/Python 3/Node. when I jump to a new python project, I always need to edit the shell.nix to

let pkgs = import {};inpkgs.mkShell { buildInputs = with pkgs; [ python3Packages.jedi python3Packages.yapf python3Packages.ipdb bashInteractive ]; shellHook = '' unset SOURCE_DATE_EPOCH ''; }

and for a Node project, I need to edit it to

let pkgs = import {};inpkgs.mkShell { buildInputs = [ pkgs.nodejs-10_x pkgs.bashInteractive ]; }

that would be great if I can specify which shell.nix file to use for lorri init

maybe something like:

search for ~/.lorri/templates/python3/shell.nix

$ lorri init python3

search for ~/.lorri/templates/node/shell.nix

$ lorri init node

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/target/lorri/issues/382#issuecomment-632009091, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYB5ZXUUF6LI7TYFQL7UFDRST6SNANCNFSM4MLI2DSQ .

[steveej]

maybe something like:

# search for ~/.lorri/templates/python3/shell.nix
$ lorri init python3

# search for ~/.lorri/templates/node/shell.nix
$ lorri init node

I've thought about this way too often before without actually implementing it as I've thought about all kinds of complexities before even starting. So the ideal solution would have composable and extensible presets. This would allow you to call something like e.g. lorri init rust musl, and later either manually add something to the local shell.nix, and also be able to add another preset with e.g. lorri add python3.

[doronbehar]

I think that's a lot to ask for the start. niv have this kind of interface as you are describing. I'm not sure how it integrates with lorri /direnv though... Personally, I don't use it because I want a simpler tool and I care less about reproducibility.

[candeira]

Given the variance in potential uses, I'd be inclined to give users a directory where they can drop their own named templates, and not pretend to be able to provide functionality that will suit everyone.

$XDG_CONFIG_HOME/lorri/templates would hold the named templates like so:

python3_with_node.shell.nix
python3_with_node.envrc
rust_with_musl.shell.nix
rust_with_musl.envrc
ziglang.shell.nix
ziglang.envrc

This is not a request, but rather a description on the design I've chosen for my local lorri templater script. I use a small number of templates, and I use them repeatedly; other people might have different needs.

[otavio]

@candeira, the proposal seems to be as flexible as needed and easy enough.

The only extra thing I can come with is to have a default (such: shell.nix and envrc) when used without a named template.

[Profpatsch]

I’m a bit hesitant to add “yet another templating system” to a tool I use. I’ve had great success with “just edit the darn file” in my personal projects :laughing:. It’s a 5 second task that I do once every few days/weeks, so I will have to refer to https://xkcd.com/1205/

[Profpatsch]

This is not a request, but rather a description on the design I've chosen for my local lorri templater script.

Do you know of any “general” templating tool that is in wide use? Maybe we can integrate lorri init with it.