feat: C template #27
48
c/flake.nix
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
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 = { ... }; } { ... } ]`
|
||||
description = "Templates for getting started with Aux";
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
inputs.nixpkgs.url = "github:auxolotl/nixpkgs/nixos-unstable";
|
||||
|
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 = { ... }; } { ... } ]`
we aren't actually updating branches besides master currently ```suggestion
inputs.nixpkgs.url = "github:auxolotl/nixpkgs";
```
we aren't actually updating branches besides master currently
master template use it too. master template use it too.
this should changed as well this should changed as well
This might need it's own dedicated issue This might need it's own dedicated issue
|
||||
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
outputs = { self, nixpkgs }:
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
let
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
forAllSystems =
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
function:
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
nixpkgs.lib.genAttrs [
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
"x86_64-linux"
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
"aarch64-linux"
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
"x86_64-darwin"
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
"aarch64-darwin"
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
"i686-linux"
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
"mipsel-linux"
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
"powerpc64le-linux"
|
||||
|
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});
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
in 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 = { ... }; } { ... } ]`
|
||||
devShells.default = 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 = { ... }; } { ... } ]`
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.
|
||||
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" ];
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
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 = { ... }; } { ... } ]`
```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?
|
||||
|
||||
|
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 {
|
||||
|
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;
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
hello = pkgs.stdenv.mkDerivation 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 = { ... }; } { ... } ]`
|
||||
name = "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 = { ... }; } { ... } ]`
|
||||
src = ./.;
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
nativeBuildInputs = [ pkgs.gnumake ];
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
enableParallelBuilding = true;
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
V = 1;
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
installPhase = ''
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
install -D ${name} $out/bin/${name} --mode 0755
|
||||
|
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 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 {
|
||||
|
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;
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
hello = builtins.mapAttrs
|
||||
|
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 = { ... }; } { ... } ]`
|
||||
(name: value: "${value.hello}/bin/hello") 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 = { ... }; } { ... } ]`
|
||||
I would prefer to not have rec, also i believe it is pname, not name