| 9 Aug 2023 |
countoren | no | 23:34:22 |
countoren | sorry | 23:34:24 |
Lily Foster | Apologies, I'm still having trouble grasping what exactly it is you are attempting here 😅 | 23:34:47 |
countoren | I didnt edit the genereated one I added those when composing them in the flake | 23:34:59 |
countoren | :) nvm i think if the token will work there is a good chance that it will solve my problem | 23:35:31 |
countoren | but as a reference this is my composed node2nix:
globalBuildInputsSet = import ./server/supplement.nix {
inherit nodeEnv;
inherit (pkgs) stdenv lib nix-gitignore fetchurl fetchgit;
};
globalBuildInputs = pkgs.lib.attrValues globalBuildInputsSet;
nodeEnv = import ./server/node-env.nix {
nodejs = nodejs13;
inherit (pkgs) stdenv lib python2 runCommand writeTextFile writeShellScript;
inherit pkgs;
libtool = if pkgs.stdenv.isDarwin then pkgs.darwin.cctools else null;
};
client = (import ./server/node-packages.nix {
inherit (pkgs) fetchurl nix-gitignore stdenv lib fetchgit;
inherit globalBuildInputs nodeEnv;
sourcesOverride = srcs:
srcs // {
"@fortawesome/pro-light-svg-icons-5.14.0" = srcs."@fortawesome/pro-light-svg-icons-5.14.0" // {
src = ./server/fortawesome-pro-light-svg-icons-5.14.0.tgz;
};
"@fortawesome/pro-solid-svg-icons-5.14.0" = srcs."@fortawesome/pro-solid-svg-icons-5.14.0" // {
src = ./server/fortawesome-pro-solid-svg-icons-5.14.0.tgz;
};
"@fortawesome/fontawesome-common-types-0.2.30" = srcs."@fortawesome/fontawesome-common-types-0.2.30" // {
src = ./server/fortawesome-fontawesome-common-types-0.2.30.tgz;
};
"@fortawesome/fontawesome-svg-core-1.2.30" = srcs."@fortawesome/fontawesome-svg-core-1.2.30" // {
src = ./server/fortawesome-fontawesome-svg-core-1.2.30.tgz;
};
"@fortawesome/angular-fontawesome-0.5.0" = srcs."@fortawesome/angular-fontawesome-0.5.0" // {
src = ./server/fortawesome-angular-fontawesome-0.5.0.tgz;
};
};
});
| 23:36:32 |
Lily Foster | In reply to @countoren:matrix.org :) nvm i think if the token will work there is a good chance that it will solve my problem Alright, let me know and I'll send a PR so we can get it into nixpkgs. Keep in mind buildNpmPackage/fetchNpmDeps needs a FOD hash for now separate from the package-lock.json (but one day we want a importNpmLockfile kinda like what Rust has with importCargoLock which would avoid the need for that FOD hash in most scenarios) | 23:37:09 |
countoren | what is FOD ? first time seeing this abrv :) | 23:38:30 |
Lily Foster | In reply to @countoren:matrix.org
but as a reference this is my composed node2nix:
globalBuildInputsSet = import ./server/supplement.nix {
inherit nodeEnv;
inherit (pkgs) stdenv lib nix-gitignore fetchurl fetchgit;
};
globalBuildInputs = pkgs.lib.attrValues globalBuildInputsSet;
nodeEnv = import ./server/node-env.nix {
nodejs = nodejs13;
inherit (pkgs) stdenv lib python2 runCommand writeTextFile writeShellScript;
inherit pkgs;
libtool = if pkgs.stdenv.isDarwin then pkgs.darwin.cctools else null;
};
client = (import ./server/node-packages.nix {
inherit (pkgs) fetchurl nix-gitignore stdenv lib fetchgit;
inherit globalBuildInputs nodeEnv;
sourcesOverride = srcs:
srcs // {
"@fortawesome/pro-light-svg-icons-5.14.0" = srcs."@fortawesome/pro-light-svg-icons-5.14.0" // {
src = ./server/fortawesome-pro-light-svg-icons-5.14.0.tgz;
};
"@fortawesome/pro-solid-svg-icons-5.14.0" = srcs."@fortawesome/pro-solid-svg-icons-5.14.0" // {
src = ./server/fortawesome-pro-solid-svg-icons-5.14.0.tgz;
};
"@fortawesome/fontawesome-common-types-0.2.30" = srcs."@fortawesome/fontawesome-common-types-0.2.30" // {
src = ./server/fortawesome-fontawesome-common-types-0.2.30.tgz;
};
"@fortawesome/fontawesome-svg-core-1.2.30" = srcs."@fortawesome/fontawesome-svg-core-1.2.30" // {
src = ./server/fortawesome-fontawesome-svg-core-1.2.30.tgz;
};
"@fortawesome/angular-fontawesome-0.5.0" = srcs."@fortawesome/angular-fontawesome-0.5.0" // {
src = ./server/fortawesome-angular-fontawesome-0.5.0.tgz;
};
};
});
Oh I see, yeah having the token should avoid the need to vendor those fontawesome tarballs. I would add token support to node2nix to avoid you having to rewrite code from node2nix to buildNpmPackage, but the node2nix code is highly cursed and as I mentioned there's no real investment anymore maintenance given the architectural and practical issues the approach has, unfortunately | 23:38:45 |
Lily Foster | In reply to @countoren:matrix.org what is FOD ? first time seeing this abrv :) Oh yeah, sorry, Fixed-Output Derivation. It's like when you have a fetchFromGitHub in a package and need to provide a hash of the download in advance. buildNpmPackage expects a npmDepsHash that's more or less equivalent to that, just being a hash of the fetched npm deps rather than some concrete upstream | 23:39:59 |
countoren | o ye, I noticed it. IMO it make sense and dont feel much of trouble | 23:43:38 |
countoren | the way I usually explain it to beginner it is your way to sign that this is what you want. | 23:44:34 |
Lily Foster | Yeah, that makes sense I suppose | 23:45:36 |
Lily Foster | In reply to @lily:lily.flowers Okay I made a thing for passing in an environment variable that looks like NIX_NPM_TOKENS='{"regsistry.fontawesome.com":"token"}'. Do you think you could apply this patch to your nixpkgs and see if you can set NIX_NPM_TOKENS on your builder/nix daemon? https://github.com/lilyinstarlight/nixpkgs/compare/5a8e9243812ba528000995b294292d3b5e120947...24f435dd88b47f53011bc1f296fd0347699ef451.diff Oh also NIX_NPM_TOKENS needs to be set on the nix daemon if running Nix in multi-user mode (the default unless you are running as root user). I will leave it up to you on how to do that, but in general it will eventually end up being some systemd override to add Environment=NIX_NPM_TOKENS={...} (and overrides usually go in somewhere like /etc/systemd/system/nix-daemon.service.d/) | 23:47:45 |
countoren | I was thinking actually clone me a copy apply the diff and add it to my flake | 23:48:44 |
countoren | as ref | 23:48:52 |
countoren | * as absulte pat | 23:49:02 |
Lily Foster | For nixpkgs, yeah that's probably easiest | 23:49:08 |
countoren | * as absolute pat | 23:49:14 |
Lily Foster | I'm just saying to pass in the privilege token you'll need to get it into the build environment a bit awkwardly (unfortunately) | 23:49:25 |
countoren | its been a while since I worked on the actual nixpkgs. so it clean copy | 23:49:52 |
countoren | btw another way if you a branch or fork i can point the flake directly to it | 23:50:52 |
Lily Foster | Oh yeah, sure! github:lilyinstarlight/nixpkgs/feature/prefetch-npm-deps-tokens | 23:51:40 |
countoren | the magic of flake... | 23:54:02 |
countoren | it must be on daemon? there is no way to specify it on the project's flake itself? | 23:59:05 |
| 10 Aug 2023 |
Lily Foster | Tokens are secrets, so it's not something we usually do in nixpkgs. Afaik what we usually do when fetcher info needs to be propagated to the builder we just let it impurely inherit env vars from the builder (which is admittedly very hacky and unintuitive and annoying, so if anyone knows another way fetcher secrets are propagated in nixpkgs I would be open to implementing an alternative as well) | 00:05:18 |
countoren | I w | 00:06:11 |
countoren | yes it make sense but It might be fine to have a quick way if someone want to define them the uncleaner way they can with a warning maybe | 00:08:11 |
countoren | well I guess if you really want you can always hack a quick writeshellscript to change you secrets on the service | 00:11:12 |
countoren | but for beginners it might not be that straightforward | 00:11:49 |