My shellify tool for quickly generating shell.nix files is now in unstable nixpkgs.
After installing dependencies by running nix-shell -p mydep, it can be a little effort to produce the shell.nix (and flake.nix if you wish). This tool does that for you and makes it quick and simple.
I posted a about this a while ago but was encouraged by reviewers on Github to re-post when on nixpkgs.
I created nixos.org inspired asciinema animations that show the use case better than I can explain in prose. Just watch the examples and you’ll see how the tool helps.
For those that don’t use flakes the tool can be used like this:
And for those that do use flakes the tool can be used like this:
Please take a look, and give it a try. Feedback more than welcome.
10 Likes
This is great. Something like this should be upstreamed. I think it would be equivalent to guix shell —export-manifest.
1 Like
I‘d wish for the demo and the front page to show output samples. Otherwise one has to actually try it out or dig into the code to figure out what that thing even does. From the tests one can see that the input uses the angle bracket path to Nixpkgs, which for me is a no-go. At the very least it should point to the release branch tarball that corresponds to the current channel. Then there would be no opportunity for random breakage. Possibly it should pin to the precise commit, at least as an option. In any case it should not rely on channels, I don’t know anyone who would recommend to continue promoting their use.
I also think that at the surface this tool provides such a straightforward and useful feature, it should be available out of the box. For it to have a chance to get accepted upstream in Nix it should entail a minimal, obvious change and leave no questions up to debate. For example, should that really be a function with a default pkgs argument or should it be a let binding? What if NIX_PATH is not set or no channels are configured? Unless you have a very convincing proposal, it will be a hard sell to maintainers to spend time thinking about the stable CLI and especially nix-shell given how many issues there are with it already. I’m personally in favor of small improvements to stable interfaces as long as we don’t have solutions concerning the new CLI and flakes, but it has to be economical, also and especially with respect to long-term maintenance.
1 Like
Thanks for all the feedback Valentin. I’ll get the output samples added to the text on front page and share the PR with you. Updating the demo may take a little longer as it’s more work to change.
From the tests one can see that the input uses the angle bracket path to Nixpkgs, which for me is a no-go
This is just the default. It can be overridden. When using flakes this is all pinned down in flake.lock as expected. If you use flake syntax you’ll get this behavior. If not add --with-flake to get it.
At the very least it should point to the release branch tarball that corresponds to the current channel
Can we do better than this for the non-flake scenario? I’d be happy to change to this behavior if that’s the consensus. Personally I get the same by using flakes but I don’t know how everybody else is working and wants to work right now.
I also think that at the surface this tool provides such a straightforward and useful feature, it should be available out of the box
I agree with you and @asymmetric on this. If this tool is superseded by something out of the box I’m happy too. I won’t have the time unfortunately to start something new as I start a new role very soon but hopefully development of this tool helps flesh out something that eventually makes it’s way upstream.
1 Like
I love this idea, thanks for creating this! Seems super convenient. Would love to see it upstreamed for sure.
For those of you who use or plan to use this tool, will you
a) use the new flake style e.g. nix-shellify shell mydep as per the flake demo above;
b) use the old nix-shell style and pass the switch to request a flake to be generated e.g. nix-shellify --with-flake -p mydep as per the non-flake demo above; or
c) use the old style without generating a flake e.g. nix-shellify -p mydep.
If you think you will use c, would you prefer a shell.nix pointing to a pinned down release and how would you like it to look?
As it turns out, the new style syntax is far less complicated to parse but I have no idea who uses it already or wants to use it. All three options work right now but option c is not pinned down in any way and I’d rather see examples of what’s desired before implementing anything. I won’t remove any functionality that anybody tells me is being used.