Is there a reason `npmlock2nix` is not available in `nixpkgs`?

[kolpav]

Hello,

Thank you for this project its the only one I managed to get to work and I think I tried them all. I use flakes or plain default.nix/shell.nix files and its bit cumbersome to make them runable from outside of flake where I have npmlock2nix overlay it would make things much easier for me if this project was part of nixpkgs. I am thinking about creating PR there so I am curious if theres a reason its not already there.

[andir]

The plan was to comitt to a stable API with as little as known bugs before that happens. These days I am not convinced it is actually a good idea. As you mentioned you are using flakes so composing repositories is rather simple for you already.

This projects default.nix is written in a way that allows you to use it with any nixpkgs version: The cumbersome part is doing the overlaying as you said. That comes down to flakes not really being a top-notch UX IMO. They force thinking about the system attribute on you all the time. In the old world (before flakes) that usually was a concern that you had once while writing your expression or at worst another time when writing hydra jobsets. Now you've to think about it the entire time while writing your flake expression. I also don't want to start dictating a potential ancient nixpkgs version by providing a flake in this repository. nixpkgs should always be an input to this repositroy that the caller manages. Yes you can use the follows attribute in the inputs section but that requires actively thinking about it as a user. Only exposing an interface that enforces passing in nixpkgs is the right way IMO.

The best way is probably to have something like numtides flake-utils and integrate it into a functiont hat you call for each architecture. I still hestitate comitting to a flake.nix in this repository as I don't want to support an already broken UX. See #63 #112 #159

[kolpav]

First of all I am totally new to nix I gave up and picked up like 5 times till I decided to install it everywhere and force myself to use it.

The thing that helped me enormously to get anything done were the flakes finally there was some structure to the chaos. I found it funny that the only thing that I was able to use was not only experimental but also controversial and I see bit of parallel with your project the only project that you can use to develop not just package your react/vue/angular/svelte app screams at you at every occasion how unstable it is when in fact its only one I find stable :smile: the tests, prepared shell, node_modules copy or link, documentation... really high level of polish :pray: . Next time there's something experimental or unstable in nix community is going to be clear signal for me to use it, but I know that stability != usability :) in your case.

I appreciate your response but I am not sure I entirely get it

That comes down to flakes not really being a top-notch UX IMO. They force thinking about the system attribute

By system attribute you mean x86_64-linux? That also tripped me as a newbie

I also don't want to start dictating a potential ancient nixpkgs version by providing a flake in this repository

How would having flake dictate nixpkgs version? Because there would be flake.lock or is there some other technical reason?

I still hestitate comitting to a flake.nix in this repository as I don't want to support an already broken UX

Understandable.

[andir]

How would having flake dictate nixpkgs version? Because there would be flake.lock or is there some other technical reason?

That is exactly it. If we went with that a simple flake could look like this:

{
   inputs.npmlock2nix.url = "github:nix-community/npmlock2nix";
   outputs = { npmlock2nix, ... }: {
      packages.x86_64-linux.my-app = npmlock2nix.build { src = ./.; };
   };
}

That is all. In that case you'd rely on the nixpkgs version that was bundled with npmlock2nix. You can override that on the consumer side (follows attribute) but in that case you are stuck with that way of defining nixpkgs. If we wanted to support cases where someone uses different version of nixpkgs with npmlock2nix within the same flake (without importing npmlock2nix multiple times with different follows's) we must support multiple entry-points to the flake.

A better interface that we could implement potentially is something like this:

{
   inputs.npmlock2nix.url = "github:nix-community/npmlock2nix";
   outputs = { npmlock2nix, nixpkgs, ... }: {
      packages.x86_64-linux.my-app = (npmlock2nix nixpkgs.legacyPackages.x86_64-linux).build  { src = ./.; };
   };
}

That looks more ergonomic but still repeats the system parameter a couple of times. For me flakes in general or rather the nixpkgs flake must learn to integrate with external "extensions" that aren't always overlays. My opinion on overalys is tha they shouldn't be used more of the time. You want to write your own set of packages that depends on nixpkgs.