You don’t need flake-utils when inlining that loop is around 4 lines of code. Every downstream project now has to manage that dependency. It’s not worth it with lib already having the glue you need to make it yourself.
Introducing Nix just for the devShells is such a waste since you’re missing a lot of the advantages & going straight to a mutable, stateful environment. Not to say folks can’t start there or that the author shouldn’t be writing about their experience, but there are already heaps of “make a devShell” posts on Lobsters that it’s borderline spam to post one for every language given it’s all the same mkShell.
I agree flake-utils is unnecessary here, and personally think for places where it is necessary other solutions are better. Unfortunately it’s been a popular solution so it continues to be reused given the breadth of prior art using FU. Personally I like flake-parts, but as you said nixpkgs lib is sufficient.
I disagree though about this being borderline spam and think even if you use it for nothing else there is a lot of value in nix dev shells. There are important details that different languages require, as evidenced by this specific post. You want code reload, you need inotify, etc. Sure, this isn’t taking full advantage of what nix has to offer, but that’s ok. We should be making nix a solution for all kinds of different uses, not diminishing the desires for others to use the tools.
Introducing Nix just for the devShells is such a waste since you’re missing a lot of the advantages
How is it a waste if it’s improving someone’s development setup substantially? For example by being able to easily manage various versions of languages, linters, formatters etc without having to bother about language-specific solutions? And then sharing the config with coworkers? Those are some of the advantages of Nix.
& going straight to a mutable, stateful environment.
Are you referring to the fact that they don’t use Nix to manage the mix packages (in this case)? I really wish that dream2nix or something like it would become mature enough that it would be easy for newcomers to use Nix for language packages as well. Or if the dream2nix vision is impractical (I have no idea), that the documentation around existing solutions for different languages was approachable enough. Right now, it feels like hit and miss to get it working without sliding into that distinct Nixy feeling of spinning wheels getting further stuck in the mud.
it’s borderline spam to post one for every language
I somewhat agree. It’s great that people write these posts, but it’s only of interest in the particular case that you need a quick reference for a specific setup.
It is impractical but sadly it is because there are no good existing solutions.
Bridging the worlds of programming language package manager with the world of C/Cpp/OS package managers which are also build systems like Nix is still a mostly void research domain.
Would love more work in there though!
My hunch is that we would need a standard on how they interact/an API; which would need to be managed and implemented mostly on the programming language package manager sides. Because they control the versionning, metadata and update distribution channels, which means they cannot adapt to nix needs.
So nix needs to adapt to what they can provide and tell them what they need to implement. So that we can keep the contract working when the package managers change.
A lot of teams might be better suited with something like asdf or a VM/container at a specific hash if all they want is specific binary versions as it’s more flexible than picking a singular version or trying to find a maintain the nixpkgs hashes for said versions. If folks think the immutability/reproducibility is good, then they should be building the whole project as a derivation–just like the packages from nixpkgs they are relying on. You then get features like the ability to run multiple builders in parallel, sharing derivations via substitutors between machines/collaborators, etc. that you don’t get by keeping just a mutable shell. The tooling is already set up to build in a stateless sandbox. One needs to consider if how immutability helps build their output too, not just gets their tools for them.
It’s been a while since I used it, but I found dream2nix was trying to do a tad to much & I needed to make a deeper override to some packages & it was more difficult than choosing a dedicated *2nix project. You can build derivations as is & most popular languages already have good enough documentations in the doc/languages-frameworks/ directory of Nix package. Like how the C/C++ land doesn’t really have package managers & you often rely on the system libraries, often times it just easier to use the libraries Nix provides you per language than trying to wrangle another package manager inside your package manager, Nix. Networking enough to find a maintainer/approver isn’t a huge barrier to get something into nixpkgs proper too if your specific library isn’t yet in the package set–so long as you can label yourself the maintainer, you can upstream whatever you need (and in the meantime, your unmerged/unapproved patch can be an overlay).
Does this involve drinking more Kool-Aid? Yes, but learning your tools is normal & there are, at least to me, clear advantages to going all-in rather than one-foot-in-one-foot-out by just using a devShell.
there are, at least to me, clear advantages to going all-in rather than one-foot-in-one-foot-out by just using a devShell.
All I’m saying is, people usually walk by putting one foot in front of the other. If you never take the first step, how are you ever going to take the second one.
Not to say folks can’t start there or that the author shouldn’t be writing about their experience, but there are already heaps of “make a devShell” posts
The problem is there are so many of these posts that stop here & the idea keeps persisting this is where you can stop. I’ve seen teams walk away from Nix saying it wasn’t offering them that much because it wasn’t offering them much or they were trying to glue it together with Bazel or Docker instead of letting it do it’s normal infection thing as it’s already a damn good package manager. By all means let that be a gateway, but a) post more content about what to do next and/or b) no need to rehash each language’s toolset on a link aggregator.
As for other ways to go over walking thru Nix packaging/architecture ideas, I (shamelessly, but honestly proudly) took a stab at teaching from the packages angle first last year. The logic of the post can follow any tool despite a Vim plugin being an used as a concrete example & devShells were almost a footnote at the end since they really aren’t too important if the thing you want to ship is already in a Nix derivation.
For the sake of record (and also because I have a flake.nix in mind that I’d probably immediately apply this to), can you show the code that removes the flake-utils dependency by inlining it out?
Also, I appreciate your frustration but may suggest that if us Nix fans want to bring more people in, that a more constructive/supportive approach to tone might be more helpful
The way I inline said for loop, but I’ve seem some other good, concise options too, but don’t recall where I saw it off the top of my head. Often better is specifically choosing your supported architectures, but in some use cases, all Unix could be fine.
You don’t need
flake-utilswhen inlining that loop is around 4 lines of code. Every downstream project now has to manage that dependency. It’s not worth it withlibalready having the glue you need to make it yourself.Introducing Nix just for the devShells is such a waste since you’re missing a lot of the advantages & going straight to a mutable, stateful environment. Not to say folks can’t start there or that the author shouldn’t be writing about their experience, but there are already heaps of “make a devShell” posts on Lobsters that it’s borderline spam to post one for every language given it’s all the same
mkShell.I agree flake-utils is unnecessary here, and personally think for places where it is necessary other solutions are better. Unfortunately it’s been a popular solution so it continues to be reused given the breadth of prior art using FU. Personally I like flake-parts, but as you said nixpkgs lib is sufficient.
I disagree though about this being borderline spam and think even if you use it for nothing else there is a lot of value in nix dev shells. There are important details that different languages require, as evidenced by this specific post. You want code reload, you need inotify, etc. Sure, this isn’t taking full advantage of what nix has to offer, but that’s ok. We should be making nix a solution for all kinds of different uses, not diminishing the desires for others to use the tools.
How is it a waste if it’s improving someone’s development setup substantially? For example by being able to easily manage various versions of languages, linters, formatters etc without having to bother about language-specific solutions? And then sharing the config with coworkers? Those are some of the advantages of Nix.
Are you referring to the fact that they don’t use Nix to manage the mix packages (in this case)? I really wish that dream2nix or something like it would become mature enough that it would be easy for newcomers to use Nix for language packages as well. Or if the dream2nix vision is impractical (I have no idea), that the documentation around existing solutions for different languages was approachable enough. Right now, it feels like hit and miss to get it working without sliding into that distinct Nixy feeling of spinning wheels getting further stuck in the mud.
I somewhat agree. It’s great that people write these posts, but it’s only of interest in the particular case that you need a quick reference for a specific setup.
It is impractical but sadly it is because there are no good existing solutions.
Bridging the worlds of programming language package manager with the world of C/Cpp/OS package managers which are also build systems like Nix is still a mostly void research domain.
Would love more work in there though!
My hunch is that we would need a standard on how they interact/an API; which would need to be managed and implemented mostly on the programming language package manager sides. Because they control the versionning, metadata and update distribution channels, which means they cannot adapt to nix needs.
So nix needs to adapt to what they can provide and tell them what they need to implement. So that we can keep the contract working when the package managers change.
A lot of teams might be better suited with something like asdf or a VM/container at a specific hash if all they want is specific binary versions as it’s more flexible than picking a singular version or trying to find a maintain the nixpkgs hashes for said versions. If folks think the immutability/reproducibility is good, then they should be building the whole project as a derivation–just like the packages from nixpkgs they are relying on. You then get features like the ability to run multiple builders in parallel, sharing derivations via substitutors between machines/collaborators, etc. that you don’t get by keeping just a mutable shell. The tooling is already set up to build in a stateless sandbox. One needs to consider if how immutability helps build their output too, not just gets their tools for them.
It’s been a while since I used it, but I found dream2nix was trying to do a tad to much & I needed to make a deeper override to some packages & it was more difficult than choosing a dedicated *2nix project. You can build derivations as is & most popular languages already have good enough documentations in the
doc/languages-frameworks/directory of Nix package. Like how the C/C++ land doesn’t really have package managers & you often rely on the system libraries, often times it just easier to use the libraries Nix provides you per language than trying to wrangle another package manager inside your package manager, Nix. Networking enough to find a maintainer/approver isn’t a huge barrier to get something into nixpkgs proper too if your specific library isn’t yet in the package set–so long as you can label yourself the maintainer, you can upstream whatever you need (and in the meantime, your unmerged/unapproved patch can be an overlay).Does this involve drinking more Kool-Aid? Yes, but learning your tools is normal & there are, at least to me, clear advantages to going all-in rather than one-foot-in-one-foot-out by just using a devShell.
All I’m saying is, people usually walk by putting one foot in front of the other. If you never take the first step, how are you ever going to take the second one.
Quoting myself earlier 😅
The problem is there are so many of these posts that stop here & the idea keeps persisting this is where you can stop. I’ve seen teams walk away from Nix saying it wasn’t offering them that much because it wasn’t offering them much or they were trying to glue it together with Bazel or Docker instead of letting it do it’s normal infection thing as it’s already a damn good package manager. By all means let that be a gateway, but a) post more content about what to do next and/or b) no need to rehash each language’s toolset on a link aggregator.
As for other ways to go over walking thru Nix packaging/architecture ideas, I (shamelessly, but honestly proudly) took a stab at teaching from the packages angle first last year. The logic of the post can follow any tool despite a Vim plugin being an used as a concrete example & devShells were almost a footnote at the end since they really aren’t too important if the thing you want to ship is already in a Nix derivation.
That’s an excellent post. Please write more :)
I appreciate that since it was my first time trying to make something less rambling since it wasn’t my personal blog.
For the sake of record (and also because I have a flake.nix in mind that I’d probably immediately apply this to), can you show the code that removes the flake-utils dependency by inlining it out?
Also, I appreciate your frustration but may suggest that if us Nix fans want to bring more people in, that a more constructive/supportive approach to tone might be more helpful
The way I inline said for loop, but I’ve seem some other good, concise options too, but don’t recall where I saw it off the top of my head. Often better is specifically choosing your supported architectures, but in some use cases, all Unix could be fine.
This is a good lead at least; bookmarked, thanks!