Refactor nix files

[deemp]

• Added an overlay so that one can add nix2container to pkgs.
• Moved all attributes into nix2container, so that one doesn't need to write nix2container.nix2container.
• Simplified callPackage expressions using this new attrset structure
• Updated readme example
  • Discouraged shadowing by using outputs: inputs
  • Showed how to use the overlay

[deemp]

@nlewo, please, check when you have time

[nlewo]

Hello @deemp and thanks for your contribution!

FYI, we actually had an overlay which has been removed for performance issues... See #3

Would we have the same issue with your proposition?

[deemp]

@nlewo, I want a mechanism to use nix2container with arbitrary pkgs without inputs.nix2container.nixpkgs.follows. Can I achieve that without an overlay? Yes, if the repo provides a function mkNix2container = {pkgs}: .... Does this mean the repo shouldn't provide an overlay? Not really.

I believe we will have no performance issues. In the article (link) linked in the issue #3, the author writes about performance issues when using two different versions of nixpkgs in flake inputs, not when using overlays.

Especially with the advent of Flakes, soon enough, we will end up with 1000 dependencies, each with its own instance of nixpkgs. Given that nixpkgs takes around 100MiB of RAM and a second to evaluate, that can quickly add up.

In a discussion, the author says it's okay to use overlays in certain cases (link).

That’s right. This is a limitation of how the flakes work; there is no mechanism to override flakes. For that use-case, each flake would also have to expose an overlay. Probably this should be part of a dedicated Flakes best practices article.

A commenter states that per-overlay overhead is minimal (link).

[psionic-k]

          pkgs = import nixpkgs {
            inherit system;
            overlays = [
              inputs.fenix.overlays.default
              inputs.nix2container.overlays.default
            ];
          };

This is the way.

Without this style, I see that my input is bringing along its own packages and wonder if they are from nixpkgs-22.05 or whatever. In general, proliferation of nixpkgs versions should only be used as a last resort, so overlay style of use, which presumes to be consumed with the user's version of nixpkgs, is the correct default usage pattern.

Btw

trace: warning: `vendorSha256` is deprecated. Use `vendorHash` instead

I'm just evaluating tools and saw this PR.

[MaxDaten]

trace: warning: vendorSha256 is deprecated. Use vendorHash instead

Which now fails in application:

cachix/devenv#1083