Make legacyPackages look like pkgs in a nixos module

[jmbaur]

Description of changes

This change the package set in legacyPackages.<system> look the same as it would in a nixos module using jetpack-nixos, so the same pkgs.nvidia-jetpack is present in both.

Testing

N/A

[danielfullmer]

Is this actually needed? It creates another import of nixpkgs and nothing in jetpack-nixos should be directly consuming itself via pkgs.nvidia-jetpack, that should just be for external users

[jmbaur]

It creates another import of nixpkgs

Where would the other import of nixpkgs be? My understanding of this change is that it moves the import of nixpkgs from https://github.com/nixos/nixpkgs/blob/592c139bdb42bf14ae13d183ec85221a4dbd9c81/flake.nix#L86 to this flake directly.

Is this actually needed?

Not at all, but I think it brings a few benefits.

1. If we have any documentation that shows example usage of jetpack-nixos in a nixos configuration, any use of jetpack-nixos derivations will come from pkgs.nvidia-jetpack, so a user can simply use the same attribute path when using nix build, nix run, etc. against this flake.
2. By defining our own custom package set and putting it on legacyPackages, we don't get to take advantage of any paradigms that exist in nixpkgs such as pkgsCross.
3. The flake output schema docs (https://nixos.wiki/wiki/Flakes) say legacyPackages is for nixpkgs packages, so us using it as a way to amend our own packages to nixpkgs instead of overriding it entirely feels more true to that description.

[danielfullmer]

It creates another import of nixpkgs

Where would the other import of nixpkgs be? My understanding of this change is that it moves the import of nixpkgs from https://github.com/nixos/nixpkgs/blob/592c139bdb42bf14ae13d183ec85221a4dbd9c81/flake.nix#L86 to this flake directly.

I was thinking the nixpkgs.lib, but after looking at upstream's flake.nix it looks like it doesn't actually instantiate a nixpkgs fixpoint if you just grab nixpkgs.lib.

Is this actually needed?

Not at all, but I think it brings a few benefits.

1. If we have any documentation that shows example usage of jetpack-nixos in a nixos configuration, any use of jetpack-nixos derivations will come from pkgs.nvidia-jetpack, so a user can simply use the same attribute path when using nix build, nix run, etc. against this flake.
2. By defining our own custom package set and putting it on legacyPackages, we don't get to take advantage of any paradigms that exist in nixpkgs such as pkgsCross.
3. The flake output schema docs (https://nixos.wiki/wiki/Flakes) say legacyPackages is for nixpkgs packages, so us using it as a way to amend our own packages to nixpkgs instead of overriding it entirely feels more true to that description.

I actually dislike exposing the entire nixpkgs set from flakes outside of nixpkgs unless the overlay actually modified something that affects things in the top-level package set. Providing the whole package set implies that our overlay does more than it does (e.g. building pkgs.hello is the same as upstream nixpkgs). I just want the packages in nvidia-jetson exposed. Also, this changes the flake interface to jetpack-nixos in a backwards-incompatible way and I don't think this is worth it.