nodePackages: are (mostly) broken

[offlinehacker]

We need to replace current implementation with what has @svanderburg done in https://github.com/svanderburg/npm2nix/tree/reengineering, but i need your help to do that. I'm currently unable to make some packages and nixos modules, because of that.

[domenkozar]

What help do you need?

[offlinehacker]

Well sander has changed a lot of things in generated expressions, he made
his own buildNodePackage, now i would like to know what are integration
plans of his work.
On Dec 23, 2014 9:31 PM, "Domen Kožar" [email protected] wrote:

What help do you need?

—
Reply to this email directly or view it on GitHub
#5450 (comment).

[domenkozar]

@svanderburg are you planing to get your npm2nix fork into nixpkgs tree?

[svanderburg]

@iElectric @offlinehacker Hi, integration of the new npm2nix is possible, but it has one major drawback. It relies on a trick in which Nix expressions are generated inside a derivation that gets imported, which is a controversial feature. @rbvermaa for example was very critical about this and I also want to avoid it if I can.

Although the new npm2nix works fine for me, I'm not sure this issue is a blocker. I have an alternative solution in mind in which I try to propagate the resolve dependencies ahead of time (e.g. npm2nix calculates them and generates the expressions accordingly), but that generates bigger and more complicated Nix expressions and requires a bit of work.

We can also simply accept that the new npm2nix has this drawback, proceed, and solve this issue later.

I'm not sure what you think?

[offlinehacker]

Another alternative would be usage of fromJSON, but i don't think importing
generated expressions is so contraversial.

Currently i think any solution that works (deterministically) is better
than the current solution, and we can improve later.

It's a blocker, if i can't package nodejs packages in a sane way and if
some core JavaScript tools like bower do not work.
On Dec 24, 2014 1:47 PM, "Sander van der Burg" [email protected]
wrote:

@iElectric https://github.com/iElectric @offlinehacker
https://github.com/offlinehacker Hi, integration of the new npm2nix is
possible, but it has one major drawback. It relies on a trick in which Nix
expressions are generated inside a derivation that gets imported, which is
a controversial feature. @rbvermaa https://github.com/rbvermaa for
example was very critical about this and I also want to avoid it if I can.

Although the new npm2nix works fine for me, I'm not sure this issue is a
blocker. I have an alternative solution in mind in which I try to propagate
the resolve dependencies ahead of time (e.g. npm2nix calculates them and
generates the expressions accordingly), but that generates bigger and more
complicated Nix expressions and requires a bit of work.

We can also simply accept that the new npm2nix has this drawback, proceed,
and solve this issue later.

I'm not sure what you think?

—
Reply to this email directly or view it on GitHub
#5450 (comment).

[wmertens]

👍 on replacing broken solution with working solution that needs
optimization.

On Wed, Dec 24, 2014, 2:00 PM Jaka Hudoklin [email protected]
wrote:

Another alternative would be usage of fromJSON, but i don't think
importing
generated expressions is so contraversial.

Currently i think any solution that works (deterministically) is better
than the current solution, and we can improve later.

It's a blocker, if i can't package nodejs packages in a sane way and if
some core JavaScript tools like bower do not work.
On Dec 24, 2014 1:47 PM, "Sander van der Burg" [email protected]
wrote:

@iElectric https://github.com/iElectric @offlinehacker
https://github.com/offlinehacker Hi, integration of the new npm2nix
is
possible, but it has one major drawback. It relies on a trick in which
Nix
expressions are generated inside a derivation that gets imported, which
is
a controversial feature. @rbvermaa https://github.com/rbvermaa for
example was very critical about this and I also want to avoid it if I
can.

Although the new npm2nix works fine for me, I'm not sure this issue is a
blocker. I have an alternative solution in mind in which I try to
propagate
the resolve dependencies ahead of time (e.g. npm2nix calculates them and
generates the expressions accordingly), but that generates bigger and
more
complicated Nix expressions and requires a bit of work.

We can also simply accept that the new npm2nix has this drawback,
proceed,
and solve this issue later.

I'm not sure what you think?

—
Reply to this email directly or view it on GitHub
#5450 (comment).

—
Reply to this email directly or view it on GitHub
#5450 (comment).

[offlinehacker]

Ok, i analyzed solution from @svanderburg and as far as i can see it can be done simpler, but still thanks for providing all the solutions. I will try to fix current buildNodePackage, with these changes #4922 and all the great stuff @svanderburg has done.

[offlinehacker]

@svanderburg What's the benefit behind this smart version detection for recursive dependencies? As far as i understand it should not matter if only exact versions are matched, then it's up to npm to choose what he wants and from nix point of view it works.

[offlinehacker]

Closing this, as it was fixed.