Open doronbehar opened 4 years ago
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?
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.
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
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 notifications@github.com 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 .
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
.
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.
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.
@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.
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/
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.
Feature description
Every time I run
lorri init
, I edit this:To become:
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.