A follow-up post from 1000 instances of nixpkgs
7 Likes
For all the details and more, see:
What a cliffhanger 
1 Like
Addressed here stdenv/check-meta: add note for Flake usage by MatthewCroughan · Pull Request #145714 · NixOS/nixpkgs · GitHub
2 Likes
Oh, and I thought you’re announcing a binary cache for all the unfree packages, as a reaction to some recent discussion on them missing in cache.nixos.org
6 Likes
Heh, I would be open to doing that as well. First I need to extend the CI so it keeps the channels in sync. It makes sense to add a Cachix cache on top.
The nix-data channel/group had looked at some of the issues of distributing some of the unfree packages. Legal topics around patching (via pathelf) CUDA and NVIDIA come up often.
2 Likes
I’m not sure if this is a good thing.
In my opinion your flake is abusing a bug in nixpkgs.
Flakes allow easy injection of “unfree” software into the system of the user who consumes a flake.
I still prefer the NIXPKGS_ALLOW_UNFREE=1/--impure combination, as it gives me the control over the licenses I am willing to violate
Are we going to create a flake now for every combination of configuration arguments given to Nixpkgs?
7 Likes
When there is a problem, someone is going to find a solution
The nix-data channel/group had looked at some of the issues of distributing some of the unfree packages. Legal topics around patching (via pathelf) CUDA and NVIDIA come up often.
Assuming all the derivations and licenses are added appropriately, this would already be handled with the non-redistributable license flag. I would be in favour of taking a do-and-apologize approach with this, as long as it doesn’t put the main NixOS project at risk.
This is already the case today, except that if a project creates its own nixpkgs instance, it won’t be visibility until reading its source code. The dependency tree is something that can be inspected from the outside.
Until Flakes adds a “use flags” type of feature, where flakes can be parameterized, I don’t really see a better way. Alternatively, we could split nixpkgs itself.
4 Likes
And then have something like nix build --with-config ./config.nix .#attr where parameters are loaded from the file? This could be interpreted as --impure but significantly smaller in scope. Like @NobbZ I also typically use --impure for unfree builds, but would prefer not to use it since it can do more impure things than I’d like to have.
2 Likes
It doesn’t have to be impure at all. But flakes would need to be extended and become a proper package manager. If you look at Cargo, NPM, Pip, Cabal, … pretty much all of them support some sort of feature flag feature. A flake could be able to declare variants it supports, and then other flakes can depend on that flake with the given variant.
{
description = "my flake"
// IDEA: Tell flakes we want to use nixpkgs with unfree packages
inputs.nixpkgs.config = { allowUnfree = true; }
// IDEA: My own variants, including which systems to support
config = { systems = ["x86_64-linux"]; };
outputs = { self, nixpkgs }:
// access the config with self.config or nixpkgs.config
{
packages = nixpkgs.lib.genAttrs self.config.systems (system: {
# Now I can access unfree packages
slack = nixpkgs.slack;
});
};
}
8 Likes
If I understand well, this snippet is not valid at the moment, right ?
Not exactly this snippet, but:
inputs.nixpkgs.url = "github:numtide/nixpkgs-unfree";
cf. GitHub - numtide/nixpkgs-unfree: nixpkgs with the unfree bits enabled
Just in case you’re also interested in using CUDA-enabled packages, you might want to have a look at CUDA - NixOS Wiki
Ok ! Thank you for this precision !
I also made it work using the following:
let
pkgs = import nixpkgs {
system = "x86_64-linux";
config = {
allowUnfree = true;
};
};
in {
3 Likes
I checked today, and the incidence of flake.nix with allowUnfree has approximately doubled since this article was first published.
- February 4, 2022: 218 results
- February 14, 2023: 484 results
2 Likes
I started playing w/ nixpkgs-unfree and I love the structure it adds to my flake, great work!!!
I created an input like this
nixpkgs-unstable.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
nixpkgs-unstable-unfree = {
url = "github:numtide/nixpkgs-unfree";
inputs.nixpkgs.follows = "nixpkgs-unstable";
};
but when adding the input to the nix registry using
nix.registry.nixpkgs-unstable-unfree.flake = inputs.nixpkgs-unstable-unfree;
weird things start to happen:
A nix search nixpkgs-unstable-unfree#anytype returns an old version 0.29.1, while nix search github:numtide/nixpkgs-unfree/nixpkgs-unstable#anytype returns version 0.33.3 (the expected result).
Version 0.29.1 correlates with the nixpkgs commit captured in nixpkgs-unfree flake.lock file https://github.com/numtide/nixpkgs-unfree/blob/2708e517eff25a904f914d2368feef0dccc2a969/flake.lock#L9
I wonder if this setup supported after all?
Hi! I had the exact same problem. The follows statement does not propoagate to the registry entry, which only copies or links the flake as is. I moved back to maintaining a personal nixpkgs-unfree flake, which has the same nixpkgs version as used on my current system.
Try this instead:
nixpkgs-unstable-unfree = {
url = "github:numtide/nixpkgs-unfree/nixpkgs-unstable";
};
nixpkgs-unstable and nixos-unstable branches are getting automatically synched daily from upstream.
Please correct me if I’m wrong @zimbatm but doesnt your solution lead to 2 syncs of nixpkgs-unstable ?
I do love the idea that both my nixpkgs-unstable and nixpkgs-unstable-unfree contain exactly the same packages down to the commit hash I synced. That sync could break than, right?
1 Like