error: 'nixinate' is not a valid system type

wyndon commented

2022-03-15 16:24:38 +00:00

(Migrated from github.com)

When running nix flake check, it complains about nixinate not being a valid system type

❯ nix flake check
error: 'nixinate' is not a valid system type, at /nix/store/n3gxibvxm0i4zkdb5s6dkalwsyr5qni6-source/flake.nix:46:14
(use '--show-trace' to show detailed location information)

When running `nix flake check`, it complains about nixinate not being a valid system type ```sh ❯ nix flake check error: 'nixinate' is not a valid system type, at /nix/store/n3gxibvxm0i4zkdb5s6dkalwsyr5qni6-source/flake.nix:46:14 (use '--show-trace' to show detailed location information) ```

MatthewCroughan commented

2022-03-23 23:57:30 +00:00

(Migrated from github.com)

The apps attribute of the flake schema wants to disallow a nested attributes like apps.myName.myNestedApp.x86_64-linux, but I believe this should be changed. So this issue may remain until the flake schema changes, or 3.0 is released which settles any debate on it.

The `apps` attribute of the flake schema wants to disallow a nested attributes like `apps.myName.myNestedApp.x86_64-linux`, but I believe this should be changed. So this issue may remain until the flake schema changes, or 3.0 is released which settles any debate on it.

👍 2 😕 1

ursi commented

2022-10-04 23:09:18 +00:00

(Migrated from github.com)

I feel like breaking nix flake check is too big of a price to pay. It seems that the only thing you want nested apps for is so you can go nixinate.foo. For now, why not just make it nixinate-foo or nixinate_foo so we can use it with nix flake check? Or at least make an alternative function that can be used for those of us that need nix flake check.

I feel like breaking `nix flake check` is too big of a price to pay. It seems that the only thing you want nested apps for is so you can go `nixinate.foo`. For now, why not just make it `nixinate-foo` or `nixinate_foo` so we can use it with nix flake check? Or at least make an alternative function that can be used for those of us that need `nix flake check`.

MatthewCroughan commented

2022-10-05 17:37:07 +00:00

(Migrated from github.com)

@ursi it's important to remember that flakes aren't stable, and that we shouldn't program with the expectation of any stability until they are. So with that in mind, it's entirely still possible to make Flakes work more like we would like them to, and to argue the point upstream.

Kranzes commented

2022-10-05 18:26:55 +00:00

(Migrated from github.com)

I think that for the meantime we should go with what @ursi proposed, making the apps flat and prefixing them with nixinate-.

I think that for the meantime we should go with what @ursi proposed, making the apps flat and prefixing them with `nixinate-`.

ursi commented

2022-10-05 21:28:32 +00:00

(Migrated from github.com)

What I have done as a workaround for now is apps.x86_64-linux = (nixinate stuff).nixinate. If I wanted the nixinate prefix on the app names I could use lib.mapAttrs', but for my current project, that's not necessary.

What I have done as a workaround for now is `apps.x86_64-linux = (nixinate stuff).nixinate`. If I wanted the `nixinate` prefix on the app names I could use `lib.mapAttrs'`, but for my current project, that's not necessary.

👍 1

quinn-dougherty commented

2022-10-27 00:55:22 +00:00

(Migrated from github.com)

(oops, duplicated) https://github.com/MatthewCroughan/nixinate/issues/31