The product of a chat with @QuazarOmega@lemy.lol
Still haven’t reached the flakes stage. An experimental feature that the maintainers are too afraid to treat as experimental and make breaking changes, but unwilling to name stable because it requires bug-fixes and changes that would be breaking, but too afraid to break because… reasons.
It’s pretty easy for home-manager use, but still really useful. You can:
- choose which packages to install from stable and which from unstable
- add packages from repos that have flake.nix in them
- correctly match nix and home-manager versions, and always update them at the same time
- allow-unfree without nixpkgs conf, so 1 less directory required in .config (if they accepted the “experimental” features it’d be down to 1)
Here’s an example:
flake.nix
{
description = "home flake";
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
home-manager.url = "github:nix-community/home-manager/master";
home-manager.inputs.nixpkgs.follows = "nixpkgs";
nixpkgs-stable.url = "github:nixos/nixpkgs/nixos-23.11";
# nixgl.url = "github:guibou/nixGL";
};
outputs =
{
self,
nixpkgs,
nixpkgs-stable,
home-manager,
# nixgl,
...
}@inputs:
let
system = "x86_64-linux";
pkgs = import nixpkgs {
system = system;
config = {
allowUnfree = true;
};
};
pkgsStable = import nixpkgs-stable {
system = system;
config = {
allowUnfree = true;
};
};
in
{
homeConfigurations = {
shareni = home-manager.lib.homeManagerConfiguration {
inherit pkgs;
modules = [ ./home.nix ];
extraSpecialArgs = {
inherit inputs;
inherit system;
kmonad = pkgsStable.kmonad;
};
};
};
};
}
The ‘code’ tag here does not respect newlines, I tried to fix it but this is the best I could do:
`{ description = “home flake”;
inputs = { nixpkgs.url = “github:nixos/nixpkgs/nixos-unstable”;
home-manager.url = “github:nix-community/home-manager/master”;
home-manager.inputs.nixpkgs.follows = “nixpkgs”;
nixpkgs-stable.url = “github:nixos/nixpkgs/nixos-23.11”;
# nixgl.url = “github:guibou/nixGL”;
};
outputs = {
self,
nixpkgs,
nixpkgs-stable,
home-manager,
# nixgl,
…
}
@inputs:
let
system = “x86_64-linux”;
pkgs = import nixpkgs {
system = system;
config = {
allowUnfree = true;
};
};
pkgsStable = import nixpkgs-stable {
system = system;
config = {
allowUnfree = true;
};
};
in {
homeConfigurations = {
shareni = home-manager.lib.homeManagerConfiguration {
inherit pkgs;
modules = [ ./home.nix ];
extraSpecialArgs = {
inherit inputs;
inherit system;
kmonad = pkgsStable.kmonad;
};
};
};
};
}`
[rest of post]
Anti Commercial-AI license
Hey look, the trend is spreading: you’re the second user I’ve seen doing that.
It’d be nice if the Lemmy devs added some sort of metadata field to support that so that (a) we could have a preference to insert it into every new comment automatically, and (b) it could be reduced to a badge on the comment header or something so that it would be less obtrusive to those of us who aren’t trying to do anything that would require us to pay attention to it.
Nix has the same mix of conceptual simplicity and atrocious user interface as git, but somehow magnified three times over. I’ve tried it multiple times, but could never get over the unintuitive gaggle of commands.
It’s much simpler because you’re using text files to define the expected state, the cli is there only to tell nix to figure out what it needs to do and to get on with it. Meanwhile with git you’re manually doing each of the steps until you reach the desired state.
I only need cd ~/dotfiles/nix/ && nix-channel --update && nix flake update && home-manager switch for everyday package management. It’s the nix version of apt update upgrade and install.
nix shell and nix run are pretty useful as well, and you’d want home-manager generations to rollback.
The confusion arises because there are 5 different ways to do the same thing, the non-experimental methods shouldn’t be used even though they’re recommended in the official docs, and you need to get lucky to get the info that you can use home-manager and that one liner.
The confusion arises because there are 5 different ways to do the same thing, the non-experimental methods shouldn’t be used even though they’re recommended in the official docs
I appreciate what you’re trying to say, but you’re kind of illustrating exactly the point I was making about conceptual simplicity and atrocious UX.
You’re ignoring the difference between using something declaratory and imperatively. Just because it’s difficult to get to that one liner, it doesn’t change the fact you’ll still only use that one command. Git by it’s nature requires you to use different commands to achieve different results. Home-manager allows you to both update your packages and delete all of them with the same command, because that command is “sync the state with the source of truth”.
Have you considered GUIX instead? Same concept, but with added GNU and configured entirely with Guile Scheme, apparently.
It’s far better in theory, but in practice it’s got some massive issues:
- non-free packages are taboo in the official guix community
- binary support was lacking the last time I used it (firefox didn’t have a precompiled bin for example, and that means you need to leave your browser to compile overnight)
- far less packages than nixpkgs even when you account for the non-free repo
- packages are seriously out of date (I tried using it as an additional pm a few months ago, and debian 12 was newer in a lot of cases)
- essentially no support for some programming languages and package managers (node and npm for example)
In it’s current state it’s really only good for emacs, lisps, and some other languages like haskell.
…which are going to die
I started with NixOS and now I installed something called “Lix”
Yeah I’m deep in it to return
The product of a chat with @QuazarOmega@lemy.lol
Can confirm, very productive indeed ;)
There is only a way forward, and once you start, you cannot stop
