Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[flakes] best practices/ feature: override nixpkgs config for permittedInsecurePackages #1354

Open
schmittlauch opened this issue Oct 22, 2023 · 1 comment

Comments

@schmittlauch
Copy link

Describe the issue

When having to deal with an existing 3rd party poetry.lock file, it might happen that some of the dependencies in there have benn marked as insecure in nixpkgs. Current examples are openssl_1_1 or some older versions of python-requests.
Using insecure packages is not nice, but at times necessary.

To allow the usage of these packages, the nixpkgs config attribute permittedInsecurePackages needs to be modified.

In a flake with the 2 inputs nixpkgs and poetry2nix, just instantiating nixpkgs with a new config is not enough as the poetry2nix flake also takes nixpkgs as an input. And this input is not affected by the re-configuration within the flake outputs body.

I'd like to know whether there are existing best practices for this. maybe we can document them? If not, there might be a need to provide nixpkgs config to the poetry2nix flake from the outside?

suggestion

I managed to solve this issue by using a separate sub-flake to configure and then re-export nixpkgs. This sub-flake output is then fed into both poetry2nix via follows and used instead of the main nixpkgs in the main flake.

the toplevel flake.nix:

{
  inputs = {
    myNixpkgs = {
      url = "./flakeSupport/myNixpkgs";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    nixpkgs = {
      #url = "github:NixOS/nixpkgs/nixos-23.05";
      url = "nixpkgs";
    };
    nixpkgsOld.url = "github:NixOS/nixpkgs/nixos-21.05";
    poetry2nix = {
      url = "github:nix-community/poetry2nix";
      inputs.nixpkgs.follows = "myNixpkgs";
    };
  };

  outputs = { self, myNixpkgs, poetry2nix, ... }:
    let
      inherit (myNixpkgs) lib;
      supportedSystems = [ "x86_64-linux" "x86_64-darwin" "aarch64-linux" "aarch64-darwin" ];
      forAllSystems = lib.genAttrs supportedSystems;
      pkgs = forAllSystems (system: myNixpkgs.legacyPackages.${system});
      p2n = forAllSystems (system: poetry2nix.legacyPackages.${system});
    in
    {
      devShells = forAllSystems (system: {
        default = pkgs.${system}.mkShellNoCC {
          packages = with pkgs.${system}; [
            (p2n.${system}.mkPoetryEnv poetryCommonOpts.${system})
            pkgs.${system}.python38
            poetry
            openssl_1_1
          ];
        };
      });
    };
}

The sub-flake flakeSupport/myNixpkgs/flake.nix:

# vaguely inspired by https://github.com/numtide/nixpkgs-unfree/blob/9545d844027c1b91b14b19d225856efc931b22b2/flake.nix
{
  description = "nixpkgs reexported with some required configuration, e.g. permitted insecure packages";

  outputs = inputs@{self, nixpkgs}:
  let
    inherit (nixpkgs) lib;
    # re-use same supported systems as in the upstream nixpkgs
    systems = lib.systems.flakeExposed;
    forEachSystem = lib.genAttrs systems;

    nixpkgsConfig = {
      permittedInsecurePackages = [
        "openssl-1.1.1w"
      ];
    };
  in
  nixpkgs // { legacyPackages = forEachSystem (system:
    import nixpkgs {
      inherit system;
      config = nixpkgsConfig;
    });};
}

Note that event this solution is a bit buggy, as it triggers re-locking of flake.lock at each evaluation.

@schmittlauch
Copy link
Author

I see we're currently hardcoding some allowed insecure packages in 806eb84#diff-206b9ce276ab5971a2489d75eb1b12999d4bf3843b7988cbe8d687cfde61dea0L59. Not only does this create yet another instance of nixpkgs to be evaluated, it is also not really sustainable regarding maintenance and customisability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant