feat: C template #27
16
c/flake.nix
|
|
@ -19,13 +19,12 @@
|
||||||
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
] (system: function nixpkgs.legacyPackages.${system});
|
] (system: function nixpkgs.legacyPackages.${system});
|
||||||
in
|
in
|
||||||
|
Can we move the package defection to a file called default.nix Can we move the package defection to a file called default.nix
Is there a need to split the flake? it is quite small > Can we move the package defection to a file called default.nix
Is there a need to split the flake? it is quite small
It allows it to have old nix compatibility. that’s the main thing for me. Also prevents redeclaring the package a few times. It allows it to have old nix compatibility. that’s the main thing for me. Also prevents redeclaring the package a few times.
|
|||||||
rec {
|
rec {
|
||||||
devShells.default = forAllSystems (
|
devShells = forAllSystems (pkgs: {
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
pkgs:
|
default = pkgs.mkShell {
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
pkgs.mkShell {
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
hardeningDisable = [ "fortify" ];
|
hardeningDisable = [ "fortify" ];
|
||||||
```suggestion
overlays.default = final: prev: {
hello = final.callPackage ./default.nix {};
};
```
What does this do? What does this do?
this allows the user to consume the overlay and it will be added the nixpkgs list. so i could use this allows the user to consume the overlay and it will be added the nixpkgs list. so i could use `enviroment.systemPackages = [ pkgs.hello ];` instead.
doesn't this cause conflict with the nixpkgs's hello pkgs? doesn't this cause conflict with the nixpkgs's [hello](https://github.com/NixOS/nixpkgs/blob/nixos-23.11/pkgs/by-name/he/hello/package.nix#L34) pkgs?
|
|||||||
inputsFrom = pkgs.lib.attrsets.attrValues packages;
|
inputsFrom = pkgs.lib.attrsets.attrValues packages;
|
||||||
}
|
};
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
);
|
});
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
|
|
||||||
packages = forAllSystems (pkgs: rec {
|
packages = forAllSystems (pkgs: rec {
|
||||||
default = hello;
|
default = hello;
|
||||||
|
|
@ -43,9 +42,12 @@
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
};
|
};
|
||||||
});
|
});
|
||||||
|
|
||||||
apps = rec {
|
apps = forAllSystems (pkgs: rec {
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
default = hello;
|
default = hello;
|
||||||
hello = builtins.mapAttrs (name: value: "${value.hello}/bin/hello") packages;
|
hello = {
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
|
program = "${packages.${pkgs.system}.hello}/bin/hello";
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
|
type = "app";
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
};
|
};
|
||||||
|
});
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
};
|
};
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
I would prefer to not have rec, also i believe it is pname, not name I would prefer to not have rec, also i believe it is pname, not name
```suggestion
hello = pkgs.stdenv.mkDerivation {
pname = "hello";
src = ./.;
nativeBuildInputs = [ pkgs.gnumake ];
enableParallelBuilding = true;
V = 1;
installPhase = ''
install -D hello $out/bin/hello --mode 0755
'';
```
```suggestion
hello = pkgs.callPackage ./default.nix {};
```
Please change the description to something more related to C Please change the description to something more related to C
for > I would prefer to not have rec, also i believe it is pname, not name
for `mkDerivation` it's name: otherwise it would throw `error: attribute 'name' missing`
```suggestion
nixpkgs.lib.genAttrs
nixpkgs.lib.systems.flakeExposed
(system: function nixpkgs.legacyPackages.${system});
```
im not really sure why this is set? im not really sure why this is set?
```suggestion
inputsFrom = [ packages.${pkgs.system}.hello ];
```
we really only need to use ```suggestion
overlays.default = final: prev: { hello = prev.callPackage ./default.nix { }; };
```
we really only need to use `final` when passing arguments to callPackage
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use ```suggestion
```
this isn't what the app output is really meant for, and doesn't actually introduce anything new. users can still use `nix run` and `nix run .#hello` without this
To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell To me it would make more sense for this to be dynamic, because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in prismlauncher for example this also duplicates inputs due to the
> because i cant think of a scenario where you wouldn't add the build inputs of a package within the dev shell
slightly different builds of the same package. this is done in [prismlauncher](https://github.com/prismlauncher/prismlauncher) for example
this also duplicates inputs due to the `default` package (which only really slows eval time a bit, but still) and currently doesn't work at all
`lib.attrValues packages` evaluates to `[ { default = { ... }; hello = { ... }; } { default = { ... }; hello = { ... }; } { ... } ]`
|
|||||||
I would prefer to not have rec, also i believe it is pname, not name