They should probably run it, so they can test their work, but then not commit it.
So I went through the process of merging three PRs and I have a few questions because I donāt want to step on anyoneās toes. Right now I just manually cherry-picked the changes from each fork/PR and then rewrote the author to preserve the information who put in the work to add something new. I then want to run the generate.sh
for each commit. Itās now running as Iām writing this and I have no idea if this will take hours or days on my measly AMD Ryzen 7 1700.
The pragmatic alternative would be to just take the changes from all PRs, add them as a single commit, run generate.sh
once, and maybe refer to all authors in the commit message? But I donāt know GitHub well enough to determine if either of these two options will properly preserve the commit in e.g., peopleās dashboards and just in case someone really cares about having their commits to Nixpkgs properly reflected there, I thought Iād ask first.
I would have created a PR so you can see the changes but like I said generate is still running. The gist is (without the generated stuff)
nixpkgs-master (masterā3|ā) $ git shortlog --max-count=3
Changlin Li (1):
nodePackages.inliner: init at 1.13.1
Teodoro Freund (1):
Added the makam package to the nodePackages
Tobias Mayer (1):
nodePackages.clubhouse-cli: init at 2.1.0
diff --git a/pkgs/development/node-packages/default.nix b/pkgs/development/node-packages/default.nix
index 4ef3de0bb4e..c86bc964fd6 100644
--- a/pkgs/development/node-packages/default.nix
+++ b/pkgs/development/node-packages/default.nix
@@ -73,6 +73,14 @@ let
nativeBuildInputs = drv.nativeBuildInputs or [] ++ [ pkgs.psc-package self.pulp ];
});
+ makam = super.makam.override {
+ buildInputs = [ pkgs.nodejs pkgs.makeWrapper ];
+ postFixup = ''
+ wrapProgram "$out/bin/makam" --prefix PATH : ${stdenv.lib.makeBinPath [ pkgs.nodejs ]}
+ patchelf --set-interpreter ${stdenv.glibc}/lib/ld-linux-x86-64.so.2 "$out/lib/node_modules/makam/makam-bin-linux64"
+ '';
+ };
+
mirakurun = super.mirakurun.override rec {
nativeBuildInputs = with pkgs; [ makeWrapper ];
postInstall = let
diff --git a/pkgs/development/node-packages/node-packages.json b/pkgs/development/node-packages/node-packages.json
index 77b398caeec..8cd631cf070 100644
--- a/pkgs/development/node-packages/node-packages.json
+++ b/pkgs/development/node-packages/node-packages.json
@@ -18,6 +18,7 @@
, "browserify"
, "castnow"
, "clean-css-cli"
+, "clubhouse-cli"
, "coc-css"
, "coc-emmet"
, "coc-eslint"
@@ -82,6 +83,7 @@
, "gitmoji-cli"
, "graphql-cli"
, "grunt-cli"
+, "makam"
, "gtop"
, "gulp"
, "gulp-cli"
@@ -90,6 +92,7 @@
, "htmlhint"
, "http-server"
, "hueadm"
+, "inliner"
, "imapnotify"
, "indium"
, "insect"
TL;DR: I really want to help I just want to make sure I do it in the right way before automating anything.
Thank you for taking this on! Iām sure we can figure out something if we work on it.
Why after each commit? I think cherry-picking a string of commits with a generate commit at the end would work.
I have no idea if this will take hours or days on my measly AMD Ryzen 7 1700.
I remember it running pretty quickly for me. Hope it doesnāt take that long!
The idea was that running generate.sh
after each commit would preserve a working git history whereas without it you might look at a commit and determine it includes node package x
but because generate.sh
was never run it actually doesnāt
So the PR is now merged I think my next step will be to turn this into a bash script so the process is automated.
@cideM Iād like to get a node package in the regular nodePackages sets and not in a separate default.nix
- i.e Iād like to supersede this:
https://github.com/NixOS/nixpkgs/pull/96961
In favor of you cherry-picking this commit into your next round of nodePackages additions.
Iām working on an update to iosevka
, whose package.json
is linked in node-packages.json so that its dependencies are available for use at build time.
Do batching updates and not running node-packages/generate.sh
apply in this case as well? If so, how does that work with automatic updates by r-ryantm (as updates will fail to build if the dependencies change)?
Sorry Iāve been busy with some other stuff for the past two weeks but Iāll dedicate some time to the automation this weekend and do another merge PR