I first heard the phrase “eject” used in the context of ejecting a Webpack config from a Create React App application’s autoconfig. It may go back further.
Sometimes it feels like Nix was built as an expression language first, with package management features tacked on afterward. (Certainly the “I’m here for the language” contingent of the community is larger, or at least louder, than the “I just want a package manager with a sane user experience” contingent.) It’s refreshing to see this being reimagined, if only by a third party.
The Nix expression language is a simple, untyped, purely functional language. It is not a general purpose programming language. Its only purpose is to describe components and compositions.
The Nix expression language is a bare-bones purpose-built description language for the Nix store. It was always intended to facilitate the construction of something like nixpkgs, and not much else.
Maybe the expression language is a red herring. My real complaint is that there are weird gaps in the package-manager usability, while the community puts tremendous effort into other things. To be sure, I have no right to complain: it’s a FOSS project, to which I’ve donated little time and no money. But it’s frustrating when I get weird behavior like this (some output omitted for clarity):
$ nix-env --upgrade --dry-run
upgrading 'nix-2.13.3' to 'nix-2.14.1'
$ nix-env -iA nixpkgs.nix
replacing old 'nix-2.13.3'
installing 'nix-2.13.3'
Like… what’s going on here? I could try to debug it, and maybe I would even be able to figure out the answer, but it feels like the UI has lots of sharp edges like this.
There are a bunch of two year old tickets in Github where project members themselves can’t agree on what needs to be done here. Lots of weird stagnation and infighting going on there.
I think that this way (expressive base that you can build “sane user experience” on top) is quite good approach. That way Nix do not need to cover and workaround any issue, but you can build tools like one above on top of it. That allows you to “get dirty” when needed and fix problems on your own when you need it, while being “clean” when you do not need it.
Not a huge fan of YAML as a configuration language - I honestly prefer the nix language, and would like to it replace YAML rather than the other way around.
One doesn’t necessarily follow the other, no? I also prefer nix to yaml, but would love to use a nix (as in package manager/nixpkgs) wrapper that allows me to succinctly describe my config.
Fleek looks really slick, but having read the home manager documentation to me it feels like too much abstraction for me to be able to comfortably trust with my main machine.
The slick abstraction will always break at some point and then you’ll have to descend into something really quite nasty.
I like the “eject” idea, it’s a succinct way of phrasing an friction I often have with tools that wrap something more flexible.
I first heard the phrase “eject” used in the context of ejecting a Webpack config from a Create React App application’s autoconfig. It may go back further.
yeah that IS neat
NB: I am not the author, but this approach closely aligns with my ideal method for handling package and configuration management for workstations.
This looks like what I imagined when I first heard of Nix
Sometimes it feels like Nix was built as an expression language first, with package management features tacked on afterward. (Certainly the “I’m here for the language” contingent of the community is larger, or at least louder, than the “I just want a package manager with a sane user experience” contingent.) It’s refreshing to see this being reimagined, if only by a third party.
Of course, it is the other way around. Quoting p61 of the thesis introducing Nix:
The Nix expression language is a bare-bones purpose-built description language for the Nix store. It was always intended to facilitate the construction of something like
nixpkgs, and not much else.Maybe the expression language is a red herring. My real complaint is that there are weird gaps in the package-manager usability, while the community puts tremendous effort into other things. To be sure, I have no right to complain: it’s a FOSS project, to which I’ve donated little time and no money. But it’s frustrating when I get weird behavior like this (some output omitted for clarity):
Like… what’s going on here? I could try to debug it, and maybe I would even be able to figure out the answer, but it feels like the UI has lots of sharp edges like this.
There are a bunch of two year old tickets in Github where project members themselves can’t agree on what needs to be done here. Lots of weird stagnation and infighting going on there.
I think that this way (expressive base that you can build “sane user experience” on top) is quite good approach. That way Nix do not need to cover and workaround any issue, but you can build tools like one above on top of it. That allows you to “get dirty” when needed and fix problems on your own when you need it, while being “clean” when you do not need it.
Honestly the nix language is a dog syntactically and a stone around the neck of what is a really good idea around package management.
Not a huge fan of YAML as a configuration language - I honestly prefer the nix language, and would like to it replace YAML rather than the other way around.
If you like nix lang you don’t need a nix wrapper. That describes you, not the tool.
One doesn’t necessarily follow the other, no? I also prefer nix to yaml, but would love to use a nix (as in package manager/nixpkgs) wrapper that allows me to succinctly describe my config.
How does this compare with flox?
This is a wrapper around nix+homemanger
Fleek looks really slick, but having read the home manager documentation to me it feels like too much abstraction for me to be able to comfortably trust with my main machine.
The slick abstraction will always break at some point and then you’ll have to descend into something really quite nasty.