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

Extract from any flake output #21

Open
GuillaumeDesforges opened this issue Jan 11, 2024 · 5 comments
Open

Extract from any flake output #21

GuillaumeDesforges opened this issue Jan 11, 2024 · 5 comments

Comments

@GuillaumeDesforges
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
I want to get the information of my NixOS system or hydra jobs, but nixtract only extracts from the packages or legacyPackages output.

Describe the solution you'd like
I'd like to be able to extract from any flake output.

Additional context
From #19
cc @aciceri

@GuillaumeDesforges
Copy link
Collaborator Author

I'm not sure about the UX.

Should we set the root to the flake itself and let users use the --target-attribute-path to select only a specific output?

$ nixtract nixpkgs --target-attribute-path legacyPackages.x86_64-linux.python3Packages

The cons I see is the need to specify the system which goes against --target-system, but we could remove the option.

Another option I can see is to keep the default behavior, and add a new option --all-outputs (I'm not sold on the name).

$ nixtract nixpkgs --all-outputs --target-attribute-path nixosConfigurations.someconfig.config.system.build.toplevel

@ErinvanderVeen
Copy link

I'm all for increasing the flexibility of nixtract, but I think nixtract will mostly be used to access packages.XXX. This proposal will lead to a lot of typing for the most common usecase, that's not ideal.

@dorranh
Copy link
Contributor

dorranh commented Jan 12, 2024

Agreed with @ErinvanderVeen's point. I think to make the UX a bit more pleasant we could do a bit of aliasing for the default case to keep the tool simple to use for these default workflows.

@aciceri
Copy link

aciceri commented Jan 12, 2024

In my opinion nixtract should mimic the nix command as much as possible.

  • nixtract considers packages.x86_64-linux.default (I don't know if defaultPackage is still a thing). Also I'm not sure about the behavior here if that output doesn't exist.
  • nixtract .#foo considers packages.x86_64-linux.foo
  • nixtract .#checks.x86_64-linux.foo considers checks.x86_64-linux.foo
  • nixtract .#foo --extra-attribute-path .#hydraJobs.x86_64-linux --extra-attribute-path .#checks.x86_64-linux.bar .#devShells.x86_64-linux.default considers 3 packages in total, you can add --extra-attribute-path as many times you want.
  • nixtract --all-flake considers all the derivations in commonly used outputs, both ones from the "official schema" and also commonly used ones like darwinConfigurations (which I don't think are "official").

I assumed an x86_64-linux host when writing commands above, but if the builder is able to build derivations for other architectures I can't see why it shouldn't work.

In order to faithfully mimic the nix CLI behavior it could be used the nix CLI itself with nix show-derivation ....

@aciceri
Copy link

aciceri commented Mar 12, 2024

The Hercules CI agent actually uses this nix code to get all the outputs given a flake. I leave it here since it can be useful both if someone wants to vendor it directly in nixtract or if someone wants to add all the outputs to packages in order to make the current nixtract able to get all the derivations.

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

No branches or pull requests

4 participants