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

std depends on "nix2container" being called "n2c" #355

Open
jg-cantaa opened this issue Sep 26, 2023 · 3 comments
Open

std depends on "nix2container" being called "n2c" #355

jg-cantaa opened this issue Sep 26, 2023 · 3 comments

Comments

@jg-cantaa
Copy link

Due to this line:

https://github.com/divnix/std/blob/01adf87cf1ed37bcd72a90f2a4e385d76c81c825/src/std/fwlib/blockTypes/containers.nix#L30C24-L30C24

std requires downstream flakes to name "nix2container" as "n2c" in order to use the "load" action.

@Pegasust
Copy link
Contributor

This is as intended

std/flake.nix

Line 43 in 01adf87

n2c.follows = "blank";

You need to pin the n2c as the consuming flake

The naming n2c is also consistent throughout the codebase

n2c.url = "github:nlewo/nix2container";

And is "enforced" that way as well

inherit (requireInput "n2c" "github:nlewo/nix2container" "std.lib.ops.mkStandardOCI") nixpkgs dmerge n2c;

The same goes for any other horizontal integration, divnix/std would want to let you take control of the pinning since std is a framework/library, which is consistent in other swe practices, notably from Rust

I'm not sure if you meant by implicitly making the std take in nix2container by having your flake's input's nix2container named n2c, I'm quite rusty on that aspect of flake, but the intended way to use std+n2c is to have inputs.std.url = "..." AND inputs.std.inputs.n2c.follows = "nix2container" with inputs.nix2container.url = "github:nlewo/nix2container" or (untested) inputs.std.inputs.n2c.url = "github:nlewo/nix2container"

@Pegasust
Copy link
Contributor

Ah, I think I understand what you mean now, please disregard my initial comment

@blaggacao
Copy link
Collaborator

Yes, I think this is an unclean design and could / should be rather enforced from the std inputs as it is with mkOCI.

Originally, the inputs action argument was added to indeed capture inputs by name from downstream flakes.

I need to double check, but in this case I agree it could probably be curried in from std's input overloading. The key is that the binary will be from the currentSystem so regardless of the target system. But that seems possible either way.

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

3 participants