Announcing nixpkgs-unfree

A follow-up post from 1000 instances of nixpkgs

6 Likes

For all the details and more, see:

What a cliffhanger :wink:

1 Like

Addressed here https://github.com/NixOS/nixpkgs/pull/145714

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 :wink:

Are we going to create a flake now for every combination of configuration arguments given to Nixpkgs?

4 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.

2 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.

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;
      });
    };
}
4 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 {
1 Like
Hosted by Flying Circus.