Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
On Thu, Jul 14, 2016 at 4:19 AM, Tomasz Czyż wrote: > Are you sure that having multiple tools/solutions is frustrating? Maybe > it's just lack of description or documentation? > (btw, currently there is only one, Sander is trying to introduce second > "official" one if I understand situation correctly). > Actually, I think that in this case, two separate tools might be called for. For dealing with the craziness that is npm, I see two approaches. One is the nix-centric approach of the existing npm2nix: each package gets its own derivation, and dependencies are symlinked into the node_modules directory. That's simple fits most closely with the way native nix packages work. The main problem with this is that npm does "clever" things to work around problems with its design, and some npm packages have undeclared dependencies that only work because of the quirks of npm. These packages are fairly rare, but they do crop up from time to time. The other approach is more npm-centric. The idea is to mimic the quirks of npm as exactly as possible, so that all packages find themselves in exactly the environment they expect. This leads to other problems, such as slower execution and bloated derivations. So it might actually be a good idea to have two different tools, each of which make different engineering tradeoffs. Colin ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
How about: name this new one npm2nix_2 and make it the default. If you want the old one, instal npm2nix_1. On Thu, Jul 14, 2016 at 1:19 PM Tomasz Czyż wrote: > 2016-07-13 22:13 GMT+01:00 Wout Mertens : > >> Great! >> >> I tried npm2nix a few times and never really got it to work. I can't >> imagine that there are a lot of people that use npm2nix that would not be >> able to switch to your new version if it got added as npm2nix. >> > I'm just trying to show similar situation: > "I don't know if anyone is using gnome, but let's remove it because I > think it's difficult to use and nobody is using it" :-) > > I think there were some cases similar to this one before and what was > suggested to check if the binary cache is used (if people are downloading > the package) or other way to check if package is being used. > > >> Having multiple solutions for the same thing is a frustrating experience >> for people that want to start using nix for npm. I would prefer simply >> replacing npm2nix. >> > Are you sure that having multiple tools/solutions is frustrating? Maybe > it's just lack of description or documentation? > (btw, currently there is only one, Sander is trying to introduce second > "official" one if I understand situation correctly). > > Sander, maybe you could add a manual change to your PR to explain this > situation/move and how the tools can be used? > > > >> On Tue, Jul 12, 2016 at 3:00 PM Sander van der Burg < >> svanderb...@gmail.com> wrote: >> >>> Hi, >>> >>> I just created a pull request for the release-16.03 branch integrating >>> my node2nix generated package set: >>> https://github.com/NixOS/nixpkgs/pull/16886 >>> >>> I'm looking for feedback as I haven't extensively tested everything. My >>> stuff seems to work properly, though. If we find the results satisfactory, >>> I will implement the same kinds of changes for the master branch as well. >>> >>> Best, >>> >>> Sander >>> >>> >>> On Mon, Jul 11, 2016 at 10:36 AM, Nikolay Amiantov wrote: >>> One possible way is to add some attribute in current nixpkgs indicating version of checksumming scheme, e.g. `fetchgit.checksumVersion`. However, this implies that you would run something like `nix-instantiate` to determine it, and so you need access to the nixpkgs tree -- IIRC you don't have such requirements now, and adding whole complexity for just getting this version seems unreasonable. What about pushing different versions of your utility to release and master branches? I feel this could cover most usecases... On 07/11/2016 01:26 PM, Sander van der Burg wrote: > Thanks for the reference. Actually, the change in Nixpkgs makes sense, > as I never understood why any file with a .git prefix had to be removed. > Similarly, I replicated this odd behaviour in npm2nix. > > I have managed to implement a fix for this locally (which I haven't > pushed yet). The only annoying thing is that the 16.03 stable release > still uses the old git hash computation method, so I need to keep the > old method intact. > > I'm still a bit puzzled on how to proceed -- I could decide to release > my npm2nix version and use the hash computation method that works with > 16.03 since that's the stable version and what end-users should use. > Then for the master branch, people should switch to the development > version of npm2nix that implements the new strategy. The only thing I'm > afraid of is that people forget about this and push broken versions of > the Node.js packages to master. > > Alternatively, I could make both strategies configurable through a > command-line parameter, but this is not very nice either. And still, > end-users might forget about it and break the package set. -- Nikolay. >>> >>> ___ >>> nix-dev mailing list >>> nix-dev@lists.science.uu.nl >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> > > > -- > Tomasz Czyż > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
2016-07-13 22:13 GMT+01:00 Wout Mertens : > Great! > > I tried npm2nix a few times and never really got it to work. I can't > imagine that there are a lot of people that use npm2nix that would not be > able to switch to your new version if it got added as npm2nix. > I'm just trying to show similar situation: "I don't know if anyone is using gnome, but let's remove it because I think it's difficult to use and nobody is using it" :-) I think there were some cases similar to this one before and what was suggested to check if the binary cache is used (if people are downloading the package) or other way to check if package is being used. > Having multiple solutions for the same thing is a frustrating experience > for people that want to start using nix for npm. I would prefer simply > replacing npm2nix. > Are you sure that having multiple tools/solutions is frustrating? Maybe it's just lack of description or documentation? (btw, currently there is only one, Sander is trying to introduce second "official" one if I understand situation correctly). Sander, maybe you could add a manual change to your PR to explain this situation/move and how the tools can be used? > On Tue, Jul 12, 2016 at 3:00 PM Sander van der Burg > wrote: > >> Hi, >> >> I just created a pull request for the release-16.03 branch integrating my >> node2nix generated package set: >> https://github.com/NixOS/nixpkgs/pull/16886 >> >> I'm looking for feedback as I haven't extensively tested everything. My >> stuff seems to work properly, though. If we find the results satisfactory, >> I will implement the same kinds of changes for the master branch as well. >> >> Best, >> >> Sander >> >> >> On Mon, Jul 11, 2016 at 10:36 AM, Nikolay Amiantov wrote: >> >>> One possible way is to add some attribute in current nixpkgs indicating >>> version of checksumming scheme, e.g. `fetchgit.checksumVersion`. >>> However, this implies that you would run something like >>> `nix-instantiate` to determine it, and so you need access to the nixpkgs >>> tree -- IIRC you don't have such requirements now, and adding whole >>> complexity for just getting this version seems unreasonable. >>> >>> What about pushing different versions of your utility to release and >>> master branches? I feel this could cover most usecases... >>> >>> On 07/11/2016 01:26 PM, Sander van der Burg wrote: >>> > Thanks for the reference. Actually, the change in Nixpkgs makes sense, >>> > as I never understood why any file with a .git prefix had to be >>> removed. >>> > Similarly, I replicated this odd behaviour in npm2nix. >>> > >>> > I have managed to implement a fix for this locally (which I haven't >>> > pushed yet). The only annoying thing is that the 16.03 stable release >>> > still uses the old git hash computation method, so I need to keep the >>> > old method intact. >>> > >>> > I'm still a bit puzzled on how to proceed -- I could decide to release >>> > my npm2nix version and use the hash computation method that works with >>> > 16.03 since that's the stable version and what end-users should use. >>> > Then for the master branch, people should switch to the development >>> > version of npm2nix that implements the new strategy. The only thing I'm >>> > afraid of is that people forget about this and push broken versions of >>> > the Node.js packages to master. >>> > >>> > Alternatively, I could make both strategies configurable through a >>> > command-line parameter, but this is not very nice either. And still, >>> > end-users might forget about it and break the package set. >>> >>> -- >>> Nikolay. >>> >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Great! I tried npm2nix a few times and never really got it to work. I can't imagine that there are a lot of people that use npm2nix that would not be able to switch to your new version if it got added as npm2nix. Having multiple solutions for the same thing is a frustrating experience for people that want to start using nix for npm. I would prefer simply replacing npm2nix. On Tue, Jul 12, 2016 at 3:00 PM Sander van der Burg wrote: > Hi, > > I just created a pull request for the release-16.03 branch integrating my > node2nix generated package set: > https://github.com/NixOS/nixpkgs/pull/16886 > > I'm looking for feedback as I haven't extensively tested everything. My > stuff seems to work properly, though. If we find the results satisfactory, > I will implement the same kinds of changes for the master branch as well. > > Best, > > Sander > > > On Mon, Jul 11, 2016 at 10:36 AM, Nikolay Amiantov wrote: > >> One possible way is to add some attribute in current nixpkgs indicating >> version of checksumming scheme, e.g. `fetchgit.checksumVersion`. >> However, this implies that you would run something like >> `nix-instantiate` to determine it, and so you need access to the nixpkgs >> tree -- IIRC you don't have such requirements now, and adding whole >> complexity for just getting this version seems unreasonable. >> >> What about pushing different versions of your utility to release and >> master branches? I feel this could cover most usecases... >> >> On 07/11/2016 01:26 PM, Sander van der Burg wrote: >> > Thanks for the reference. Actually, the change in Nixpkgs makes sense, >> > as I never understood why any file with a .git prefix had to be removed. >> > Similarly, I replicated this odd behaviour in npm2nix. >> > >> > I have managed to implement a fix for this locally (which I haven't >> > pushed yet). The only annoying thing is that the 16.03 stable release >> > still uses the old git hash computation method, so I need to keep the >> > old method intact. >> > >> > I'm still a bit puzzled on how to proceed -- I could decide to release >> > my npm2nix version and use the hash computation method that works with >> > 16.03 since that's the stable version and what end-users should use. >> > Then for the master branch, people should switch to the development >> > version of npm2nix that implements the new strategy. The only thing I'm >> > afraid of is that people forget about this and push broken versions of >> > the Node.js packages to master. >> > >> > Alternatively, I could make both strategies configurable through a >> > command-line parameter, but this is not very nice either. And still, >> > end-users might forget about it and break the package set. >> >> -- >> Nikolay. >> > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Hi, I just created a pull request for the release-16.03 branch integrating my node2nix generated package set: https://github.com/NixOS/nixpkgs/pull/16886 I'm looking for feedback as I haven't extensively tested everything. My stuff seems to work properly, though. If we find the results satisfactory, I will implement the same kinds of changes for the master branch as well. Best, Sander On Mon, Jul 11, 2016 at 10:36 AM, Nikolay Amiantov wrote: > One possible way is to add some attribute in current nixpkgs indicating > version of checksumming scheme, e.g. `fetchgit.checksumVersion`. > However, this implies that you would run something like > `nix-instantiate` to determine it, and so you need access to the nixpkgs > tree -- IIRC you don't have such requirements now, and adding whole > complexity for just getting this version seems unreasonable. > > What about pushing different versions of your utility to release and > master branches? I feel this could cover most usecases... > > On 07/11/2016 01:26 PM, Sander van der Burg wrote: > > Thanks for the reference. Actually, the change in Nixpkgs makes sense, > > as I never understood why any file with a .git prefix had to be removed. > > Similarly, I replicated this odd behaviour in npm2nix. > > > > I have managed to implement a fix for this locally (which I haven't > > pushed yet). The only annoying thing is that the 16.03 stable release > > still uses the old git hash computation method, so I need to keep the > > old method intact. > > > > I'm still a bit puzzled on how to proceed -- I could decide to release > > my npm2nix version and use the hash computation method that works with > > 16.03 since that's the stable version and what end-users should use. > > Then for the master branch, people should switch to the development > > version of npm2nix that implements the new strategy. The only thing I'm > > afraid of is that people forget about this and push broken versions of > > the Node.js packages to master. > > > > Alternatively, I could make both strategies configurable through a > > command-line parameter, but this is not very nice either. And still, > > end-users might forget about it and break the package set. > > -- > Nikolay. > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
One possible way is to add some attribute in current nixpkgs indicating version of checksumming scheme, e.g. `fetchgit.checksumVersion`. However, this implies that you would run something like `nix-instantiate` to determine it, and so you need access to the nixpkgs tree -- IIRC you don't have such requirements now, and adding whole complexity for just getting this version seems unreasonable. What about pushing different versions of your utility to release and master branches? I feel this could cover most usecases... On 07/11/2016 01:26 PM, Sander van der Burg wrote: > Thanks for the reference. Actually, the change in Nixpkgs makes sense, > as I never understood why any file with a .git prefix had to be removed. > Similarly, I replicated this odd behaviour in npm2nix. > > I have managed to implement a fix for this locally (which I haven't > pushed yet). The only annoying thing is that the 16.03 stable release > still uses the old git hash computation method, so I need to keep the > old method intact. > > I'm still a bit puzzled on how to proceed -- I could decide to release > my npm2nix version and use the hash computation method that works with > 16.03 since that's the stable version and what end-users should use. > Then for the master branch, people should switch to the development > version of npm2nix that implements the new strategy. The only thing I'm > afraid of is that people forget about this and push broken versions of > the Node.js packages to master. > > Alternatively, I could make both strategies configurable through a > command-line parameter, but this is not very nice either. And still, > end-users might forget about it and break the package set. -- Nikolay. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
My personal preference is that the last npm2nix release supports the latest
stable Nixpkgs only. I have noticed that more things (including Hydra) seem
to break after this change in fetchgit.
On Mon, Jul 11, 2016 at 10:26 AM, Sander van der Burg wrote:
> Thanks for the reference. Actually, the change in Nixpkgs makes sense, as
> I never understood why any file with a .git prefix had to be removed.
> Similarly, I replicated this odd behaviour in npm2nix.
>
> I have managed to implement a fix for this locally (which I haven't pushed
> yet). The only annoying thing is that the 16.03 stable release still uses
> the old git hash computation method, so I need to keep the old method
> intact.
>
> I'm still a bit puzzled on how to proceed -- I could decide to release my
> npm2nix version and use the hash computation method that works with 16.03
> since that's the stable version and what end-users should use. Then for the
> master branch, people should switch to the development version of npm2nix
> that implements the new strategy. The only thing I'm afraid of is that
> people forget about this and push broken versions of the Node.js packages
> to master.
>
> Alternatively, I could make both strategies configurable through a
> command-line parameter, but this is not very nice either. And still,
> end-users might forget about it and break the package set.
>
>
>
>
> On Fri, Jul 8, 2016 at 9:40 AM, Nikolay Amiantov wrote:
>
>> This patch is needed to fix sha256 hashes for the old npm2nix -- maybe
>> it would help:
>> https://github.com/NixOS/npm2nix/pull/42
>>
>> BTW, I have updated node-packages-generated.nix with this patch
>> successfully some time ago:
>> https://github.com/NixOS/nixpkgs/pull/16137
>>
>> On 07/08/2016 12:11 AM, Sander van der Burg wrote:
>> > Well, for me personally it does not matter that much.
>> >
>> > So far, I have only seen one +1 vote for making my version the new
>> > npm2nix. However, not so long ago, I noticed that there was another
>> > incoming pull request for the vanilla npm2nix. Perhaps the person who
>> > filed it, did not know about the existence of the reengineering2 branch
>> > or this discussion thread. :)
>> >
>> > Anyway, the reason why I still haven't integrated anything yet, is this
>> > issue: https://github.com/svanderburg/npm2nix/issues/7
>> >
>> > When using the master Nixpkgs branch, it seems that npm2nix no longer
>> > computes the sha256 hashes for the git checkouts correctly. Apparently,
>> > some change in the fetchgit {} infrastructure (or a dependency thereof)
>> > causes this, but I don't know why. When using the latest stable branch
>> > of Nixpkgs (release-16.03) everything seems to work just fine.
>> >
>> > I guess this issue needs to be resolved first. IMO it's a bit useless to
>> > have NPM packages set in Nixpkgs with broken Git dependencies, even
>> > though the master Nixpkgs should not be considered stable.
>> >
>> > Besides npm2nix, other generators are affected as well -- bower2nix also
>> > seems to break in one of my use cases. I haven't checked any other
>> > lang2nix generators though :(
>>
>> --
>> Nikolay.
>>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Thanks for the reference. Actually, the change in Nixpkgs makes sense, as I
never understood why any file with a .git prefix had to be removed.
Similarly, I replicated this odd behaviour in npm2nix.
I have managed to implement a fix for this locally (which I haven't pushed
yet). The only annoying thing is that the 16.03 stable release still uses
the old git hash computation method, so I need to keep the old method
intact.
I'm still a bit puzzled on how to proceed -- I could decide to release my
npm2nix version and use the hash computation method that works with 16.03
since that's the stable version and what end-users should use. Then for the
master branch, people should switch to the development version of npm2nix
that implements the new strategy. The only thing I'm afraid of is that
people forget about this and push broken versions of the Node.js packages
to master.
Alternatively, I could make both strategies configurable through a
command-line parameter, but this is not very nice either. And still,
end-users might forget about it and break the package set.
On Fri, Jul 8, 2016 at 9:40 AM, Nikolay Amiantov wrote:
> This patch is needed to fix sha256 hashes for the old npm2nix -- maybe
> it would help:
> https://github.com/NixOS/npm2nix/pull/42
>
> BTW, I have updated node-packages-generated.nix with this patch
> successfully some time ago:
> https://github.com/NixOS/nixpkgs/pull/16137
>
> On 07/08/2016 12:11 AM, Sander van der Burg wrote:
> > Well, for me personally it does not matter that much.
> >
> > So far, I have only seen one +1 vote for making my version the new
> > npm2nix. However, not so long ago, I noticed that there was another
> > incoming pull request for the vanilla npm2nix. Perhaps the person who
> > filed it, did not know about the existence of the reengineering2 branch
> > or this discussion thread. :)
> >
> > Anyway, the reason why I still haven't integrated anything yet, is this
> > issue: https://github.com/svanderburg/npm2nix/issues/7
> >
> > When using the master Nixpkgs branch, it seems that npm2nix no longer
> > computes the sha256 hashes for the git checkouts correctly. Apparently,
> > some change in the fetchgit {} infrastructure (or a dependency thereof)
> > causes this, but I don't know why. When using the latest stable branch
> > of Nixpkgs (release-16.03) everything seems to work just fine.
> >
> > I guess this issue needs to be resolved first. IMO it's a bit useless to
> > have NPM packages set in Nixpkgs with broken Git dependencies, even
> > though the master Nixpkgs should not be considered stable.
> >
> > Besides npm2nix, other generators are affected as well -- bower2nix also
> > seems to break in one of my use cases. I haven't checked any other
> > lang2nix generators though :(
>
> --
> Nikolay.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
I think you should just go ahead and create a PR which replaces the current
npm2nix with yours and removes the currently imported nodejs nix packages -
last time I checked they were all like at least 1 major version behind anyway.
After this "cut" no libraries, only nodejs cli programs should be imported as
needed.
Discussion can continue on the PR.
Sent from my iPhone
> On 07 Jul 2016, at 23:11, Sander van der Burg wrote:
>
> Well, for me personally it does not matter that much.
>
> So far, I have only seen one +1 vote for making my version the new npm2nix.
> However, not so long ago, I noticed that there was another incoming pull
> request for the vanilla npm2nix. Perhaps the person who filed it, did not
> know about the existence of the reengineering2 branch or this discussion
> thread. :)
>
> Anyway, the reason why I still haven't integrated anything yet, is this
> issue: https://github.com/svanderburg/npm2nix/issues/7
>
> When using the master Nixpkgs branch, it seems that npm2nix no longer
> computes the sha256 hashes for the git checkouts correctly. Apparently, some
> change in the fetchgit {} infrastructure (or a dependency thereof) causes
> this, but I don't know why. When using the latest stable branch of Nixpkgs
> (release-16.03) everything seems to work just fine.
>
> I guess this issue needs to be resolved first. IMO it's a bit useless to have
> NPM packages set in Nixpkgs with broken Git dependencies, even though the
> master Nixpkgs should not be considered stable.
>
> Besides npm2nix, other generators are affected as well -- bower2nix also
> seems to break in one of my use cases. I haven't checked any other lang2nix
> generators though :(
>
>
>> On Tue, Jul 5, 2016 at 12:35 PM, Rok Garbas wrote:
>> we can still keep and old version of npm2nix in nixpkgs for ppl who use it.
>> and also a branch with old code could be created, for people that want
>> pudh bugfixes or develop further (very unlikely).
>>
>>
>> On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż wrote:
>> > Rok,
>> >
>> > what about people who are already using previous solution? Why break their
>> > workflows?
>> >
>> > 2016-07-05 7:36 GMT+01:00 Rok Garbas :
>> >>
>> >> +1 for just keeping the name npm2nix and bumping up the version.
>> >>
>> >> i'm not using it on any active project, but i'm going to in the near
>> >> future.
>> >>
>> >>
>> >>
>> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug
>> >> wrote:
>> >> > Hi Sander,
>> >> >
>> >> > sorry for my very late response. I'll make this one brief as I am sadly
>> >> > on
>> >> > my phone.
>> >> >
>> >> > I belong to one of those who tried your new npm2nix and in fact am
>> >> > already
>> >> > using it regularly. I am very much in favor of having your
>> >> > re-engineeering2
>> >> > branch replacing npm2nix as the de-facto node integration tool.
>> >> >
>> >> > I also definitely want to see the current set of auto-generated node
>> >> > packages removed from nix. They are almost exclusively *totally*
>> >> > outdated.
>> >> >
>> >> > Thank you a lot for your continued efforts on this. Working with
>> >> > npm/node is
>> >> > annoying but we are better off with your contributions.
>> >> >
>> >> > cheers,
>> >> > Tobi
>> >> >
>> >> > On 22 Jun 2016, at 20:24, Sander van der Burg
>> >> > wrote:
>> >> >
>> >> > Hello Nix and Node.js users,
>> >> >
>> >> > I have been absent for a while in this discussion, but as far as I know
>> >> > the
>> >> > state of the NPM packages in Nixpkgs is still quite bad and despite some
>> >> > discussions on the mailing list we have not really come to any consensus
>> >> > yet.
>> >> >
>> >> > As some of you may know, I have my own re-engineered version of npm2nix
>> >> > that
>> >> > lives in a specific branch in my own personal fork
>> >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few
>> >> > months
>> >> > ago, I did some major efforts in getting npm 3.x's behaviour supported,
>> >> > which I have documented in this blog post:
>> >> >
>> >> > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
>> >> >
>> >> > I have been using this reengineering2 branch for all my public and some
>> >> > of
>> >> > my private projects since the beginning of this year, and for me it
>> >> > seems to
>> >> > work quite well, despite the fact that some of npm 3.x's flat module
>> >> > installation oddities are still not accurately supported yet.
>> >> >
>> >> > I also received a couple of reports from other people claiming that
>> >> > their
>> >> > projects work and even encountered some people saying that it should
>> >> > replace
>> >> > the current npm2nix. :)
>> >> >
>> >> > Obviously, I do not want to claim that my implementation is the perfect
>> >> > solution as it (for example) is much slower than the vanilla npm2nix,
>> >> > and it
>> >> > composes the entire set of dependencies in one derivation as opposed to
>> >> > generating a Nix store path per NPM dependency.
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
This patch is needed to fix sha256 hashes for the old npm2nix -- maybe
it would help:
https://github.com/NixOS/npm2nix/pull/42
BTW, I have updated node-packages-generated.nix with this patch
successfully some time ago:
https://github.com/NixOS/nixpkgs/pull/16137
On 07/08/2016 12:11 AM, Sander van der Burg wrote:
> Well, for me personally it does not matter that much.
>
> So far, I have only seen one +1 vote for making my version the new
> npm2nix. However, not so long ago, I noticed that there was another
> incoming pull request for the vanilla npm2nix. Perhaps the person who
> filed it, did not know about the existence of the reengineering2 branch
> or this discussion thread. :)
>
> Anyway, the reason why I still haven't integrated anything yet, is this
> issue: https://github.com/svanderburg/npm2nix/issues/7
>
> When using the master Nixpkgs branch, it seems that npm2nix no longer
> computes the sha256 hashes for the git checkouts correctly. Apparently,
> some change in the fetchgit {} infrastructure (or a dependency thereof)
> causes this, but I don't know why. When using the latest stable branch
> of Nixpkgs (release-16.03) everything seems to work just fine.
>
> I guess this issue needs to be resolved first. IMO it's a bit useless to
> have NPM packages set in Nixpkgs with broken Git dependencies, even
> though the master Nixpkgs should not be considered stable.
>
> Besides npm2nix, other generators are affected as well -- bower2nix also
> seems to break in one of my use cases. I haven't checked any other
> lang2nix generators though :(
--
Nikolay.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
On 7 July 2016 at 23:11, Sander van der Burg wrote:
> Anyway, the reason why I still haven't integrated anything yet, is this
> issue: https://github.com/svanderburg/npm2nix/issues/7
>
> When using the master Nixpkgs branch, it seems that npm2nix no longer
> computes the sha256 hashes for the git checkouts correctly. Apparently, some
> change in the fetchgit {} infrastructure (or a dependency thereof) causes
> this, but I don't know why. When using the latest stable branch of Nixpkgs
> (release-16.03) everything seems to work just fine.
Could be related to
https://github.com/NixOS/nixpkgs/commit/64a072e3576daae794712d898efe0fa0f44075a0.
I think that's the commit that changed the fetchgit hash on master
(and it was not backported to stable). So these days you have to be
careful when backporting a Nix package using fetchgit from master to
stable.
- Bjørn
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Well, for me personally it does not matter that much.
So far, I have only seen one +1 vote for making my version the new npm2nix.
However, not so long ago, I noticed that there was another incoming pull
request for the vanilla npm2nix. Perhaps the person who filed it, did not
know about the existence of the reengineering2 branch or this discussion
thread. :)
Anyway, the reason why I still haven't integrated anything yet, is this
issue: https://github.com/svanderburg/npm2nix/issues/7
When using the master Nixpkgs branch, it seems that npm2nix no longer
computes the sha256 hashes for the git checkouts correctly. Apparently,
some change in the fetchgit {} infrastructure (or a dependency thereof)
causes this, but I don't know why. When using the latest stable branch of
Nixpkgs (release-16.03) everything seems to work just fine.
I guess this issue needs to be resolved first. IMO it's a bit useless to
have NPM packages set in Nixpkgs with broken Git dependencies, even though
the master Nixpkgs should not be considered stable.
Besides npm2nix, other generators are affected as well -- bower2nix also
seems to break in one of my use cases. I haven't checked any other lang2nix
generators though :(
On Tue, Jul 5, 2016 at 12:35 PM, Rok Garbas wrote:
> we can still keep and old version of npm2nix in nixpkgs for ppl who use it.
> and also a branch with old code could be created, for people that want
> pudh bugfixes or develop further (very unlikely).
>
>
> On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż
> wrote:
> > Rok,
> >
> > what about people who are already using previous solution? Why break
> their
> > workflows?
> >
> > 2016-07-05 7:36 GMT+01:00 Rok Garbas :
> >>
> >> +1 for just keeping the name npm2nix and bumping up the version.
> >>
> >> i'm not using it on any active project, but i'm going to in the near
> >> future.
> >>
> >>
> >>
> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug
> >> wrote:
> >> > Hi Sander,
> >> >
> >> > sorry for my very late response. I'll make this one brief as I am
> sadly
> >> > on
> >> > my phone.
> >> >
> >> > I belong to one of those who tried your new npm2nix and in fact am
> >> > already
> >> > using it regularly. I am very much in favor of having your
> >> > re-engineeering2
> >> > branch replacing npm2nix as the de-facto node integration tool.
> >> >
> >> > I also definitely want to see the current set of auto-generated node
> >> > packages removed from nix. They are almost exclusively *totally*
> >> > outdated.
> >> >
> >> > Thank you a lot for your continued efforts on this. Working with
> >> > npm/node is
> >> > annoying but we are better off with your contributions.
> >> >
> >> > cheers,
> >> > Tobi
> >> >
> >> > On 22 Jun 2016, at 20:24, Sander van der Burg
> >> > wrote:
> >> >
> >> > Hello Nix and Node.js users,
> >> >
> >> > I have been absent for a while in this discussion, but as far as I
> know
> >> > the
> >> > state of the NPM packages in Nixpkgs is still quite bad and despite
> some
> >> > discussions on the mailing list we have not really come to any
> consensus
> >> > yet.
> >> >
> >> > As some of you may know, I have my own re-engineered version of
> npm2nix
> >> > that
> >> > lives in a specific branch in my own personal fork
> >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few
> >> > months
> >> > ago, I did some major efforts in getting npm 3.x's behaviour
> supported,
> >> > which I have documented in this blog post:
> >> >
> >> >
> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
> >> >
> >> > I have been using this reengineering2 branch for all my public and
> some
> >> > of
> >> > my private projects since the beginning of this year, and for me it
> >> > seems to
> >> > work quite well, despite the fact that some of npm 3.x's flat module
> >> > installation oddities are still not accurately supported yet.
> >> >
> >> > I also received a couple of reports from other people claiming that
> >> > their
> >> > projects work and even encountered some people saying that it should
> >> > replace
> >> > the current npm2nix. :)
> >> >
> >> > Obviously, I do not want to claim that my implementation is the
> perfect
> >> > solution as it (for example) is much slower than the vanilla npm2nix,
> >> > and it
> >> > composes the entire set of dependencies in one derivation as opposed
> to
> >> > generating a Nix store path per NPM dependency. (I do this for a very
> >> > good
> >> > reason. For more details, please read my blog post).
> >> >
> >> > Furthermore, I have also spoken to people that suggested completely
> >> > different kinds of approaches in getting NPM supported in a Nix
> >> > environment.
> >> >
> >> > Something that I have not done yet is investigating whether this
> >> > reengineered solution could be a potential replacement for the NPM
> >> > packages
> >> > set in Nixpkgs.
> >> >
> >> > Today, I have been working on an integration pattern, and the good
> news
> >> > is:
> >> > it
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Good point! I just also made a change that adds a small disclaimer comment on top the generated expressions. On Tue, Jul 5, 2016 at 4:17 PM, Graham Christensen wrote: > You all are great! Thank you so much! > > Graham > > On Tue, Jul 5, 2016 at 8:14 AM Kamil Chmielewski > wrote: > >> +1.. I'll do this in go2nix. >> >> -- >> Kamil >> >> 2016-07-05 15:10 GMT+02:00 Rok Garbas : >> >>> +1 ... i did just that recently for pypi2nix. but i'll also add a link >>> to the project home. >>> >>> [1] >>> https://github.com/garbas/pypi2nix/commit/339aee3b149909430ebe7e3e27b8cf158addaef1 >>> >>> On Tue, Jul 5, 2016 at 2:47 PM, Graham Christensen >>> wrote: >>> > I've found myself confused by multiple projects using the same lang2nix >>> > name, and big changes in format. One consistent complaint I have is >>> the top >>> > of the file usually says: >>> > >>> > // Generated by lang2nix >>> > >>> > but having more information like a version number and a URL to the >>> project >>> > would have saved hours of searching and trying different tools. >>> Something >>> > like: >>> > >>> > // Generated by lang2nix v0.1.0 >>> > // See more at https://github.com/myuser/lang2nix >>> > >>> > would be a really nice usability adjustment. >>> > >>> > On Tue, Jul 5, 2016 at 7:36 AM Rok Garbas wrote: >>> >> >>> >> we can still keep and old version of npm2nix in nixpkgs for ppl who >>> use >>> >> it. >>> >> and also a branch with old code could be created, for people that want >>> >> pudh bugfixes or develop further (very unlikely). >>> >> >>> >> >>> >> On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż >>> >> wrote: >>> >> > Rok, >>> >> > >>> >> > what about people who are already using previous solution? Why break >>> >> > their >>> >> > workflows? >>> >> > >>> >> > 2016-07-05 7:36 GMT+01:00 Rok Garbas : >>> >> >> >>> >> >> +1 for just keeping the name npm2nix and bumping up the version. >>> >> >> >>> >> >> i'm not using it on any active project, but i'm going to in the >>> near >>> >> >> future. >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug < >>> tobias.pf...@gmx.net> >>> >> >> wrote: >>> >> >> > Hi Sander, >>> >> >> > >>> >> >> > sorry for my very late response. I'll make this one brief as I am >>> >> >> > sadly >>> >> >> > on >>> >> >> > my phone. >>> >> >> > >>> >> >> > I belong to one of those who tried your new npm2nix and in fact >>> am >>> >> >> > already >>> >> >> > using it regularly. I am very much in favor of having your >>> >> >> > re-engineeering2 >>> >> >> > branch replacing npm2nix as the de-facto node integration tool. >>> >> >> > >>> >> >> > I also definitely want to see the current set of auto-generated >>> node >>> >> >> > packages removed from nix. They are almost exclusively *totally* >>> >> >> > outdated. >>> >> >> > >>> >> >> > Thank you a lot for your continued efforts on this. Working with >>> >> >> > npm/node is >>> >> >> > annoying but we are better off with your contributions. >>> >> >> > >>> >> >> > cheers, >>> >> >> > Tobi >>> >> >> > >>> >> >> > On 22 Jun 2016, at 20:24, Sander van der Burg < >>> svanderb...@gmail.com> >>> >> >> > wrote: >>> >> >> > >>> >> >> > Hello Nix and Node.js users, >>> >> >> > >>> >> >> > I have been absent for a while in this discussion, but as far as >>> I >>> >> >> > know >>> >> >> > the >>> >> >> > state of the NPM packages in Nixpkgs is still quite bad and >>> despite >>> >> >> > some >>> >> >> > discussions on the mailing list we have not really come to any >>> >> >> > consensus >>> >> >> > yet. >>> >> >> > >>> >> >> > As some of you may know, I have my own re-engineered version of >>> >> >> > npm2nix >>> >> >> > that >>> >> >> > lives in a specific branch in my own personal fork >>> >> >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A >>> few >>> >> >> > months >>> >> >> > ago, I did some major efforts in getting npm 3.x's behaviour >>> >> >> > supported, >>> >> >> > which I have documented in this blog post: >>> >> >> > >>> >> >> > >>> >> >> > >>> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >>> >> >> > >>> >> >> > I have been using this reengineering2 branch for all my public >>> and >>> >> >> > some >>> >> >> > of >>> >> >> > my private projects since the beginning of this year, and for me >>> it >>> >> >> > seems to >>> >> >> > work quite well, despite the fact that some of npm 3.x's flat >>> module >>> >> >> > installation oddities are still not accurately supported yet. >>> >> >> > >>> >> >> > I also received a couple of reports from other people claiming >>> that >>> >> >> > their >>> >> >> > projects work and even encountered some people saying that it >>> should >>> >> >> > replace >>> >> >> > the current npm2nix. :) >>> >> >> > >>> >> >> > Obviously, I do not want to claim that my implementation is the >>> >> >> > perfect >>> >> >> > solution as it (for example) is much slower than the vanilla >>> npm2nix, >>> >> >> > and it >>> >> >> > composes the e
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
You all are great! Thank you so much! Graham On Tue, Jul 5, 2016 at 8:14 AM Kamil Chmielewski wrote: > +1.. I'll do this in go2nix. > > -- > Kamil > > 2016-07-05 15:10 GMT+02:00 Rok Garbas : > >> +1 ... i did just that recently for pypi2nix. but i'll also add a link >> to the project home. >> >> [1] >> https://github.com/garbas/pypi2nix/commit/339aee3b149909430ebe7e3e27b8cf158addaef1 >> >> On Tue, Jul 5, 2016 at 2:47 PM, Graham Christensen >> wrote: >> > I've found myself confused by multiple projects using the same lang2nix >> > name, and big changes in format. One consistent complaint I have is the >> top >> > of the file usually says: >> > >> > // Generated by lang2nix >> > >> > but having more information like a version number and a URL to the >> project >> > would have saved hours of searching and trying different tools. >> Something >> > like: >> > >> > // Generated by lang2nix v0.1.0 >> > // See more at https://github.com/myuser/lang2nix >> > >> > would be a really nice usability adjustment. >> > >> > On Tue, Jul 5, 2016 at 7:36 AM Rok Garbas wrote: >> >> >> >> we can still keep and old version of npm2nix in nixpkgs for ppl who use >> >> it. >> >> and also a branch with old code could be created, for people that want >> >> pudh bugfixes or develop further (very unlikely). >> >> >> >> >> >> On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż >> >> wrote: >> >> > Rok, >> >> > >> >> > what about people who are already using previous solution? Why break >> >> > their >> >> > workflows? >> >> > >> >> > 2016-07-05 7:36 GMT+01:00 Rok Garbas : >> >> >> >> >> >> +1 for just keeping the name npm2nix and bumping up the version. >> >> >> >> >> >> i'm not using it on any active project, but i'm going to in the near >> >> >> future. >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug > > >> >> >> wrote: >> >> >> > Hi Sander, >> >> >> > >> >> >> > sorry for my very late response. I'll make this one brief as I am >> >> >> > sadly >> >> >> > on >> >> >> > my phone. >> >> >> > >> >> >> > I belong to one of those who tried your new npm2nix and in fact >> am >> >> >> > already >> >> >> > using it regularly. I am very much in favor of having your >> >> >> > re-engineeering2 >> >> >> > branch replacing npm2nix as the de-facto node integration tool. >> >> >> > >> >> >> > I also definitely want to see the current set of auto-generated >> node >> >> >> > packages removed from nix. They are almost exclusively *totally* >> >> >> > outdated. >> >> >> > >> >> >> > Thank you a lot for your continued efforts on this. Working with >> >> >> > npm/node is >> >> >> > annoying but we are better off with your contributions. >> >> >> > >> >> >> > cheers, >> >> >> > Tobi >> >> >> > >> >> >> > On 22 Jun 2016, at 20:24, Sander van der Burg < >> svanderb...@gmail.com> >> >> >> > wrote: >> >> >> > >> >> >> > Hello Nix and Node.js users, >> >> >> > >> >> >> > I have been absent for a while in this discussion, but as far as I >> >> >> > know >> >> >> > the >> >> >> > state of the NPM packages in Nixpkgs is still quite bad and >> despite >> >> >> > some >> >> >> > discussions on the mailing list we have not really come to any >> >> >> > consensus >> >> >> > yet. >> >> >> > >> >> >> > As some of you may know, I have my own re-engineered version of >> >> >> > npm2nix >> >> >> > that >> >> >> > lives in a specific branch in my own personal fork >> >> >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A >> few >> >> >> > months >> >> >> > ago, I did some major efforts in getting npm 3.x's behaviour >> >> >> > supported, >> >> >> > which I have documented in this blog post: >> >> >> > >> >> >> > >> >> >> > >> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >> >> >> > >> >> >> > I have been using this reengineering2 branch for all my public and >> >> >> > some >> >> >> > of >> >> >> > my private projects since the beginning of this year, and for me >> it >> >> >> > seems to >> >> >> > work quite well, despite the fact that some of npm 3.x's flat >> module >> >> >> > installation oddities are still not accurately supported yet. >> >> >> > >> >> >> > I also received a couple of reports from other people claiming >> that >> >> >> > their >> >> >> > projects work and even encountered some people saying that it >> should >> >> >> > replace >> >> >> > the current npm2nix. :) >> >> >> > >> >> >> > Obviously, I do not want to claim that my implementation is the >> >> >> > perfect >> >> >> > solution as it (for example) is much slower than the vanilla >> npm2nix, >> >> >> > and it >> >> >> > composes the entire set of dependencies in one derivation as >> opposed >> >> >> > to >> >> >> > generating a Nix store path per NPM dependency. (I do this for a >> very >> >> >> > good >> >> >> > reason. For more details, please read my blog post). >> >> >> > >> >> >> > Furthermore, I have also spoken to people that suggested >> completely >> >> >> > different kinds of appr
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
+1.. I'll do this in go2nix. -- Kamil 2016-07-05 15:10 GMT+02:00 Rok Garbas : > +1 ... i did just that recently for pypi2nix. but i'll also add a link > to the project home. > > [1] > https://github.com/garbas/pypi2nix/commit/339aee3b149909430ebe7e3e27b8cf158addaef1 > > On Tue, Jul 5, 2016 at 2:47 PM, Graham Christensen > wrote: > > I've found myself confused by multiple projects using the same lang2nix > > name, and big changes in format. One consistent complaint I have is the > top > > of the file usually says: > > > > // Generated by lang2nix > > > > but having more information like a version number and a URL to the > project > > would have saved hours of searching and trying different tools. Something > > like: > > > > // Generated by lang2nix v0.1.0 > > // See more at https://github.com/myuser/lang2nix > > > > would be a really nice usability adjustment. > > > > On Tue, Jul 5, 2016 at 7:36 AM Rok Garbas wrote: > >> > >> we can still keep and old version of npm2nix in nixpkgs for ppl who use > >> it. > >> and also a branch with old code could be created, for people that want > >> pudh bugfixes or develop further (very unlikely). > >> > >> > >> On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż > >> wrote: > >> > Rok, > >> > > >> > what about people who are already using previous solution? Why break > >> > their > >> > workflows? > >> > > >> > 2016-07-05 7:36 GMT+01:00 Rok Garbas : > >> >> > >> >> +1 for just keeping the name npm2nix and bumping up the version. > >> >> > >> >> i'm not using it on any active project, but i'm going to in the near > >> >> future. > >> >> > >> >> > >> >> > >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug > >> >> wrote: > >> >> > Hi Sander, > >> >> > > >> >> > sorry for my very late response. I'll make this one brief as I am > >> >> > sadly > >> >> > on > >> >> > my phone. > >> >> > > >> >> > I belong to one of those who tried your new npm2nix and in fact am > >> >> > already > >> >> > using it regularly. I am very much in favor of having your > >> >> > re-engineeering2 > >> >> > branch replacing npm2nix as the de-facto node integration tool. > >> >> > > >> >> > I also definitely want to see the current set of auto-generated > node > >> >> > packages removed from nix. They are almost exclusively *totally* > >> >> > outdated. > >> >> > > >> >> > Thank you a lot for your continued efforts on this. Working with > >> >> > npm/node is > >> >> > annoying but we are better off with your contributions. > >> >> > > >> >> > cheers, > >> >> > Tobi > >> >> > > >> >> > On 22 Jun 2016, at 20:24, Sander van der Burg < > svanderb...@gmail.com> > >> >> > wrote: > >> >> > > >> >> > Hello Nix and Node.js users, > >> >> > > >> >> > I have been absent for a while in this discussion, but as far as I > >> >> > know > >> >> > the > >> >> > state of the NPM packages in Nixpkgs is still quite bad and despite > >> >> > some > >> >> > discussions on the mailing list we have not really come to any > >> >> > consensus > >> >> > yet. > >> >> > > >> >> > As some of you may know, I have my own re-engineered version of > >> >> > npm2nix > >> >> > that > >> >> > lives in a specific branch in my own personal fork > >> >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A > few > >> >> > months > >> >> > ago, I did some major efforts in getting npm 3.x's behaviour > >> >> > supported, > >> >> > which I have documented in this blog post: > >> >> > > >> >> > > >> >> > > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html > >> >> > > >> >> > I have been using this reengineering2 branch for all my public and > >> >> > some > >> >> > of > >> >> > my private projects since the beginning of this year, and for me it > >> >> > seems to > >> >> > work quite well, despite the fact that some of npm 3.x's flat > module > >> >> > installation oddities are still not accurately supported yet. > >> >> > > >> >> > I also received a couple of reports from other people claiming that > >> >> > their > >> >> > projects work and even encountered some people saying that it > should > >> >> > replace > >> >> > the current npm2nix. :) > >> >> > > >> >> > Obviously, I do not want to claim that my implementation is the > >> >> > perfect > >> >> > solution as it (for example) is much slower than the vanilla > npm2nix, > >> >> > and it > >> >> > composes the entire set of dependencies in one derivation as > opposed > >> >> > to > >> >> > generating a Nix store path per NPM dependency. (I do this for a > very > >> >> > good > >> >> > reason. For more details, please read my blog post). > >> >> > > >> >> > Furthermore, I have also spoken to people that suggested completely > >> >> > different kinds of approaches in getting NPM supported in a Nix > >> >> > environment. > >> >> > > >> >> > Something that I have not done yet is investigating whether this > >> >> > reengineered solution could be a potential replacement for the NPM > >> >> > packages > >> >> > set in Nixpkgs. > >
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
+1 ... i did just that recently for pypi2nix. but i'll also add a link to the project home. [1] https://github.com/garbas/pypi2nix/commit/339aee3b149909430ebe7e3e27b8cf158addaef1 On Tue, Jul 5, 2016 at 2:47 PM, Graham Christensen wrote: > I've found myself confused by multiple projects using the same lang2nix > name, and big changes in format. One consistent complaint I have is the top > of the file usually says: > > // Generated by lang2nix > > but having more information like a version number and a URL to the project > would have saved hours of searching and trying different tools. Something > like: > > // Generated by lang2nix v0.1.0 > // See more at https://github.com/myuser/lang2nix > > would be a really nice usability adjustment. > > On Tue, Jul 5, 2016 at 7:36 AM Rok Garbas wrote: >> >> we can still keep and old version of npm2nix in nixpkgs for ppl who use >> it. >> and also a branch with old code could be created, for people that want >> pudh bugfixes or develop further (very unlikely). >> >> >> On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż >> wrote: >> > Rok, >> > >> > what about people who are already using previous solution? Why break >> > their >> > workflows? >> > >> > 2016-07-05 7:36 GMT+01:00 Rok Garbas : >> >> >> >> +1 for just keeping the name npm2nix and bumping up the version. >> >> >> >> i'm not using it on any active project, but i'm going to in the near >> >> future. >> >> >> >> >> >> >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug >> >> wrote: >> >> > Hi Sander, >> >> > >> >> > sorry for my very late response. I'll make this one brief as I am >> >> > sadly >> >> > on >> >> > my phone. >> >> > >> >> > I belong to one of those who tried your new npm2nix and in fact am >> >> > already >> >> > using it regularly. I am very much in favor of having your >> >> > re-engineeering2 >> >> > branch replacing npm2nix as the de-facto node integration tool. >> >> > >> >> > I also definitely want to see the current set of auto-generated node >> >> > packages removed from nix. They are almost exclusively *totally* >> >> > outdated. >> >> > >> >> > Thank you a lot for your continued efforts on this. Working with >> >> > npm/node is >> >> > annoying but we are better off with your contributions. >> >> > >> >> > cheers, >> >> > Tobi >> >> > >> >> > On 22 Jun 2016, at 20:24, Sander van der Burg >> >> > wrote: >> >> > >> >> > Hello Nix and Node.js users, >> >> > >> >> > I have been absent for a while in this discussion, but as far as I >> >> > know >> >> > the >> >> > state of the NPM packages in Nixpkgs is still quite bad and despite >> >> > some >> >> > discussions on the mailing list we have not really come to any >> >> > consensus >> >> > yet. >> >> > >> >> > As some of you may know, I have my own re-engineered version of >> >> > npm2nix >> >> > that >> >> > lives in a specific branch in my own personal fork >> >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few >> >> > months >> >> > ago, I did some major efforts in getting npm 3.x's behaviour >> >> > supported, >> >> > which I have documented in this blog post: >> >> > >> >> > >> >> > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >> >> > >> >> > I have been using this reengineering2 branch for all my public and >> >> > some >> >> > of >> >> > my private projects since the beginning of this year, and for me it >> >> > seems to >> >> > work quite well, despite the fact that some of npm 3.x's flat module >> >> > installation oddities are still not accurately supported yet. >> >> > >> >> > I also received a couple of reports from other people claiming that >> >> > their >> >> > projects work and even encountered some people saying that it should >> >> > replace >> >> > the current npm2nix. :) >> >> > >> >> > Obviously, I do not want to claim that my implementation is the >> >> > perfect >> >> > solution as it (for example) is much slower than the vanilla npm2nix, >> >> > and it >> >> > composes the entire set of dependencies in one derivation as opposed >> >> > to >> >> > generating a Nix store path per NPM dependency. (I do this for a very >> >> > good >> >> > reason. For more details, please read my blog post). >> >> > >> >> > Furthermore, I have also spoken to people that suggested completely >> >> > different kinds of approaches in getting NPM supported in a Nix >> >> > environment. >> >> > >> >> > Something that I have not done yet is investigating whether this >> >> > reengineered solution could be a potential replacement for the NPM >> >> > packages >> >> > set in Nixpkgs. >> >> > >> >> > Today, I have been working on an integration pattern, and the good >> >> > news >> >> > is: >> >> > it seems that I was able to generate Nix expressions for almost all >> >> > packages >> >> > that are in pkgs/top-level/node-packages.json. The only exceptions >> >> > were >> >> > the >> >> > node-xmpp-* and bip-* packages, but some of them seem to have broken >> >> > depende
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
I've found myself confused by multiple projects using the same lang2nix name, and big changes in format. One consistent complaint I have is the top of the file usually says: // Generated by lang2nix but having more information like a version number and a URL to the project would have saved hours of searching and trying different tools. Something like: // Generated by lang2nix v0.1.0 // See more at https://github.com/myuser/lang2nix would be a really nice usability adjustment. On Tue, Jul 5, 2016 at 7:36 AM Rok Garbas wrote: > we can still keep and old version of npm2nix in nixpkgs for ppl who use it. > and also a branch with old code could be created, for people that want > pudh bugfixes or develop further (very unlikely). > > > On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż > wrote: > > Rok, > > > > what about people who are already using previous solution? Why break > their > > workflows? > > > > 2016-07-05 7:36 GMT+01:00 Rok Garbas : > >> > >> +1 for just keeping the name npm2nix and bumping up the version. > >> > >> i'm not using it on any active project, but i'm going to in the near > >> future. > >> > >> > >> > >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug > >> wrote: > >> > Hi Sander, > >> > > >> > sorry for my very late response. I'll make this one brief as I am > sadly > >> > on > >> > my phone. > >> > > >> > I belong to one of those who tried your new npm2nix and in fact am > >> > already > >> > using it regularly. I am very much in favor of having your > >> > re-engineeering2 > >> > branch replacing npm2nix as the de-facto node integration tool. > >> > > >> > I also definitely want to see the current set of auto-generated node > >> > packages removed from nix. They are almost exclusively *totally* > >> > outdated. > >> > > >> > Thank you a lot for your continued efforts on this. Working with > >> > npm/node is > >> > annoying but we are better off with your contributions. > >> > > >> > cheers, > >> > Tobi > >> > > >> > On 22 Jun 2016, at 20:24, Sander van der Burg > >> > wrote: > >> > > >> > Hello Nix and Node.js users, > >> > > >> > I have been absent for a while in this discussion, but as far as I > know > >> > the > >> > state of the NPM packages in Nixpkgs is still quite bad and despite > some > >> > discussions on the mailing list we have not really come to any > consensus > >> > yet. > >> > > >> > As some of you may know, I have my own re-engineered version of > npm2nix > >> > that > >> > lives in a specific branch in my own personal fork > >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few > >> > months > >> > ago, I did some major efforts in getting npm 3.x's behaviour > supported, > >> > which I have documented in this blog post: > >> > > >> > > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html > >> > > >> > I have been using this reengineering2 branch for all my public and > some > >> > of > >> > my private projects since the beginning of this year, and for me it > >> > seems to > >> > work quite well, despite the fact that some of npm 3.x's flat module > >> > installation oddities are still not accurately supported yet. > >> > > >> > I also received a couple of reports from other people claiming that > >> > their > >> > projects work and even encountered some people saying that it should > >> > replace > >> > the current npm2nix. :) > >> > > >> > Obviously, I do not want to claim that my implementation is the > perfect > >> > solution as it (for example) is much slower than the vanilla npm2nix, > >> > and it > >> > composes the entire set of dependencies in one derivation as opposed > to > >> > generating a Nix store path per NPM dependency. (I do this for a very > >> > good > >> > reason. For more details, please read my blog post). > >> > > >> > Furthermore, I have also spoken to people that suggested completely > >> > different kinds of approaches in getting NPM supported in a Nix > >> > environment. > >> > > >> > Something that I have not done yet is investigating whether this > >> > reengineered solution could be a potential replacement for the NPM > >> > packages > >> > set in Nixpkgs. > >> > > >> > Today, I have been working on an integration pattern, and the good > news > >> > is: > >> > it seems that I was able to generate Nix expressions for almost all > >> > packages > >> > that are in pkgs/top-level/node-packages.json. The only exceptions > were > >> > the > >> > node-xmpp-* and bip-* packages, but some of them seem to have broken > >> > dependencies, which is not npm2nix's fault. > >> > > >> > If we would proceed integrating, we have a number of practical > >> > implications: > >> > > >> > - I believe it is desired to have both Node.js 4.x and Node.js 5.x, > 6.x > >> > supported (I actually need all of them). To support all of these, we > >> > need > >> > two different sets of generated Nix expressions. The former uses npm > 2.x > >> > with the classic dependency addressing approach and t
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
we can still keep and old version of npm2nix in nixpkgs for ppl who use it. and also a branch with old code could be created, for people that want pudh bugfixes or develop further (very unlikely). On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż wrote: > Rok, > > what about people who are already using previous solution? Why break their > workflows? > > 2016-07-05 7:36 GMT+01:00 Rok Garbas : >> >> +1 for just keeping the name npm2nix and bumping up the version. >> >> i'm not using it on any active project, but i'm going to in the near >> future. >> >> >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug >> wrote: >> > Hi Sander, >> > >> > sorry for my very late response. I'll make this one brief as I am sadly >> > on >> > my phone. >> > >> > I belong to one of those who tried your new npm2nix and in fact am >> > already >> > using it regularly. I am very much in favor of having your >> > re-engineeering2 >> > branch replacing npm2nix as the de-facto node integration tool. >> > >> > I also definitely want to see the current set of auto-generated node >> > packages removed from nix. They are almost exclusively *totally* >> > outdated. >> > >> > Thank you a lot for your continued efforts on this. Working with >> > npm/node is >> > annoying but we are better off with your contributions. >> > >> > cheers, >> > Tobi >> > >> > On 22 Jun 2016, at 20:24, Sander van der Burg >> > wrote: >> > >> > Hello Nix and Node.js users, >> > >> > I have been absent for a while in this discussion, but as far as I know >> > the >> > state of the NPM packages in Nixpkgs is still quite bad and despite some >> > discussions on the mailing list we have not really come to any consensus >> > yet. >> > >> > As some of you may know, I have my own re-engineered version of npm2nix >> > that >> > lives in a specific branch in my own personal fork >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few >> > months >> > ago, I did some major efforts in getting npm 3.x's behaviour supported, >> > which I have documented in this blog post: >> > >> > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >> > >> > I have been using this reengineering2 branch for all my public and some >> > of >> > my private projects since the beginning of this year, and for me it >> > seems to >> > work quite well, despite the fact that some of npm 3.x's flat module >> > installation oddities are still not accurately supported yet. >> > >> > I also received a couple of reports from other people claiming that >> > their >> > projects work and even encountered some people saying that it should >> > replace >> > the current npm2nix. :) >> > >> > Obviously, I do not want to claim that my implementation is the perfect >> > solution as it (for example) is much slower than the vanilla npm2nix, >> > and it >> > composes the entire set of dependencies in one derivation as opposed to >> > generating a Nix store path per NPM dependency. (I do this for a very >> > good >> > reason. For more details, please read my blog post). >> > >> > Furthermore, I have also spoken to people that suggested completely >> > different kinds of approaches in getting NPM supported in a Nix >> > environment. >> > >> > Something that I have not done yet is investigating whether this >> > reengineered solution could be a potential replacement for the NPM >> > packages >> > set in Nixpkgs. >> > >> > Today, I have been working on an integration pattern, and the good news >> > is: >> > it seems that I was able to generate Nix expressions for almost all >> > packages >> > that are in pkgs/top-level/node-packages.json. The only exceptions were >> > the >> > node-xmpp-* and bip-* packages, but some of them seem to have broken >> > dependencies, which is not npm2nix's fault. >> > >> > If we would proceed integrating, we have a number of practical >> > implications: >> > >> > - I believe it is desired to have both Node.js 4.x and Node.js 5.x, 6.x >> > supported (I actually need all of them). To support all of these, we >> > need >> > two different sets of generated Nix expressions. The former uses npm 2.x >> > with the classic dependency addressing approach and the latter uses npm >> > 3.x >> > with flat module installations. >> > - I think most library packages should be removed from >> > node-packages.json: >> > as explained in my blog post: how a package gets composed and to which >> > version a range resolve depends on the state of the includer. When >> > somebody >> > wants their own NPM project to be deployed, he should use npm2nix >> > directly >> > on package.json, and not refer to any NPM libraries in Nixpkgs. >> > - Some NPM packages must be overridden to provide native dependencies. >> > The >> > mechanisms that the reengineering2 branch use are different. It would >> > probably take a bit of effort to get these migrated. >> > >> > For example, this is how I override the webdrvr package to provide >> > phantomjs >> > and the Selenium webdriv
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Ok good to hear! The reason why I would take the pragmatic approach is because I know from experience that any kind of fundamental change (regardless of whether is good or bad) will take time for people to accept. Having two versions makes it possible for people to gradually accept and to smoothly make the transition to a new solution. Forcing people to unexpectedly do this will not make them happy. On Tue, Jul 5, 2016 at 9:44 AM, Johannes Bornhold < johannes.bornh...@gmail.com> wrote: > Hi > > > On 04 Jul 2016, at 17:34, Sander van der Burg > wrote: > > > > So far only one response... > Sorry, was silent agreement on my end ;) > > > I'm planning to implement the most pragmatic approach very soon -- due > to lack of a better/cooler name I'll rename my fork of npm2nix to node2nix. > > > > Moreover, I will add a second attribute set to Nixpkgs allowing people > to deploy packages that have been generated with node2nix. Also, I will > take the original node-packages.json as a basis, but I will remove the > library packages that I believe that should not be in there. > > > > Because the old package set will still be there, nobody should be > disrupted and meanwhile people can try/test the new approach. > > > > Any objections? > > I've looked into you fork already, looks very positive to me. Appreciate > your work on it and also the in-depth background explanation in your blog. > :) > > I am using mainly pip2nix and npm2nix in my projects to generate package > sets, willing to switch to node2nix soonish. > > From my perspective, I would even take a switch under the same name, even > if it would mean a few hazzles for me potentially to get things up and > running again. On the other side, esp. if people use it and get such a > change as a surprise, it can be negative, since they would be forces to > switch fast or get the old npm2nix available still. At least a fallback > option to get the old npm2nix easily would be good to have if we keep the > same name for the new thing. > > Cheers, Johannes > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Thank you for the responses so far To remind you about the set of packages I intend to include: I only want end-user software (such as command-line utilities) and packages that are dependencies of non-NPM projects to appear in Nixpkgs. All the other packages will be removed from node-packages.json. On Tue, Jul 5, 2016 at 9:56 AM, Michael Fellinger wrote: > For what it’s worth, I’m using the re-engineeering2 branch standalone for > projects with hundreds of npm dependencies. The way I use it right now is > like this: > > https://gist.github.com/manveru/20d22586d9dceae90930be528cbc49ce > > Having it as a part of nixpkgs would be nice, but won’t really change how > I build and use it, and having npm dependencies listed in nixpkgs isn’t > very productive, the ecosystem for JS libraries changes so fast, that we’d > have to automatically update the index every day and hope nothing breaks, > people depending on js libraries listed in nixpkgs will always be > frustrated. > > I prefer having the checksums generated by npm2nix, and giving each app > that is packaged in nixpkgs their own list of dependencies generated by > npm2nix. > > So for now, I think adding it under a different name to nixpkgs and > gradually changing things to use the new approach might be the best > solution. > > There are two things that I’m still hoping could be done better: one is > that the location to the package.json should be more flexible, while you > can specify where it is located when running npm2nix, it won’t be found > later when it’s in a directory above the one you put the npm2nix-generated > files in. I opted for putting npm-generated files into their own > subdirectory, and then run > > `ln -s "$(nix-build ./nix/npm.nix -A > package)/lib/node_modules/myapp/node_modules" node_modules` > > Maybe there’s a better way, but that’s what I figured out on my own. > > On 5 July 2016 at 11:17:05, Tomasz Czyż (tomasz.c...@gmail.com) wrote: > > Rok, > > what about people who are already using previous solution? Why break their > workflows? > > 2016-07-05 7:36 GMT+01:00 Rok Garbas : > >> +1 for just keeping the name npm2nix and bumping up the version. >> >> i'm not using it on any active project, but i'm going to in the near >> future. >> >> >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug >> wrote: >> > Hi Sander, >> > >> > sorry for my very late response. I'll make this one brief as I am sadly >> on >> > my phone. >> > >> > I belong to one of those who tried your new npm2nix and in fact am >> already >> > using it regularly. I am very much in favor of having your >> re-engineeering2 >> > branch replacing npm2nix as the de-facto node integration tool. >> > >> > I also definitely want to see the current set of auto-generated node >> > packages removed from nix. They are almost exclusively *totally* >> outdated. >> > >> > Thank you a lot for your continued efforts on this. Working with >> npm/node is >> > annoying but we are better off with your contributions. >> > >> > cheers, >> > Tobi >> > >> > On 22 Jun 2016, at 20:24, Sander van der Burg >> wrote: >> > >> > Hello Nix and Node.js users, >> > >> > I have been absent for a while in this discussion, but as far as I know >> the >> > state of the NPM packages in Nixpkgs is still quite bad and despite some >> > discussions on the mailing list we have not really come to any consensus >> > yet. >> > >> > As some of you may know, I have my own re-engineered version of npm2nix >> that >> > lives in a specific branch in my own personal fork >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few >> months >> > ago, I did some major efforts in getting npm 3.x's behaviour supported, >> > which I have documented in this blog post: >> > >> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >> > >> > I have been using this reengineering2 branch for all my public and some >> of >> > my private projects since the beginning of this year, and for me it >> seems to >> > work quite well, despite the fact that some of npm 3.x's flat module >> > installation oddities are still not accurately supported yet. >> > >> > I also received a couple of reports from other people claiming that >> their >> > projects work and even encountered some people saying that it should >> replace >> > the current npm2nix. :) >> > >> > Obviously, I do not want to claim that my implementation is the perfect >> > solution as it (for example) is much slower than the vanilla npm2nix, >> and it >> > composes the entire set of dependencies in one derivation as opposed to >> > generating a Nix store path per NPM dependency. (I do this for a very >> good >> > reason. For more details, please read my blog post). >> > >> > Furthermore, I have also spoken to people that suggested completely >> > different kinds of approaches in getting NPM supported in a Nix >> environment. >> > >> > Something that I have not done yet is investigating whether this >> > reengineered solution
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
For what it’s worth, I’m using the re-engineeering2 branch standalone for projects with hundreds of npm dependencies. The way I use it right now is like this: https://gist.github.com/manveru/20d22586d9dceae90930be528cbc49ce Having it as a part of nixpkgs would be nice, but won’t really change how I build and use it, and having npm dependencies listed in nixpkgs isn’t very productive, the ecosystem for JS libraries changes so fast, that we’d have to automatically update the index every day and hope nothing breaks, people depending on js libraries listed in nixpkgs will always be frustrated. I prefer having the checksums generated by npm2nix, and giving each app that is packaged in nixpkgs their own list of dependencies generated by npm2nix. So for now, I think adding it under a different name to nixpkgs and gradually changing things to use the new approach might be the best solution. There are two things that I’m still hoping could be done better: one is that the location to the package.json should be more flexible, while you can specify where it is located when running npm2nix, it won’t be found later when it’s in a directory above the one you put the npm2nix-generated files in. I opted for putting npm-generated files into their own subdirectory, and then run `ln -s "$(nix-build ./nix/npm.nix -A package)/lib/node_modules/myapp/node_modules" node_modules` Maybe there’s a better way, but that’s what I figured out on my own. On 5 July 2016 at 11:17:05, Tomasz Czyż (tomasz.c...@gmail.com) wrote: Rok, what about people who are already using previous solution? Why break their workflows? 2016-07-05 7:36 GMT+01:00 Rok Garbas : > +1 for just keeping the name npm2nix and bumping up the version. > > i'm not using it on any active project, but i'm going to in the near > future. > > > > On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug > wrote: > > Hi Sander, > > > > sorry for my very late response. I'll make this one brief as I am sadly > on > > my phone. > > > > I belong to one of those who tried your new npm2nix and in fact am > already > > using it regularly. I am very much in favor of having your > re-engineeering2 > > branch replacing npm2nix as the de-facto node integration tool. > > > > I also definitely want to see the current set of auto-generated node > > packages removed from nix. They are almost exclusively *totally* > outdated. > > > > Thank you a lot for your continued efforts on this. Working with > npm/node is > > annoying but we are better off with your contributions. > > > > cheers, > > Tobi > > > > On 22 Jun 2016, at 20:24, Sander van der Burg > wrote: > > > > Hello Nix and Node.js users, > > > > I have been absent for a while in this discussion, but as far as I know > the > > state of the NPM packages in Nixpkgs is still quite bad and despite some > > discussions on the mailing list we have not really come to any consensus > > yet. > > > > As some of you may know, I have my own re-engineered version of npm2nix > that > > lives in a specific branch in my own personal fork > > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few > months > > ago, I did some major efforts in getting npm 3.x's behaviour supported, > > which I have documented in this blog post: > > > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html > > > > I have been using this reengineering2 branch for all my public and some > of > > my private projects since the beginning of this year, and for me it > seems to > > work quite well, despite the fact that some of npm 3.x's flat module > > installation oddities are still not accurately supported yet. > > > > I also received a couple of reports from other people claiming that their > > projects work and even encountered some people saying that it should > replace > > the current npm2nix. :) > > > > Obviously, I do not want to claim that my implementation is the perfect > > solution as it (for example) is much slower than the vanilla npm2nix, > and it > > composes the entire set of dependencies in one derivation as opposed to > > generating a Nix store path per NPM dependency. (I do this for a very > good > > reason. For more details, please read my blog post). > > > > Furthermore, I have also spoken to people that suggested completely > > different kinds of approaches in getting NPM supported in a Nix > environment. > > > > Something that I have not done yet is investigating whether this > > reengineered solution could be a potential replacement for the NPM > packages > > set in Nixpkgs. > > > > Today, I have been working on an integration pattern, and the good news > is: > > it seems that I was able to generate Nix expressions for almost all > packages > > that are in pkgs/top-level/node-packages.json. The only exceptions were > the > > node-xmpp-* and bip-* packages, but some of them seem to have broken > > dependencies, which is not npm2nix's fault. > > > > If we would proceed integrating, we have a number of practical >
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Hi > On 04 Jul 2016, at 17:34, Sander van der Burg wrote: > > So far only one response... Sorry, was silent agreement on my end ;) > I'm planning to implement the most pragmatic approach very soon -- due to > lack of a better/cooler name I'll rename my fork of npm2nix to node2nix. > > Moreover, I will add a second attribute set to Nixpkgs allowing people to > deploy packages that have been generated with node2nix. Also, I will take the > original node-packages.json as a basis, but I will remove the library > packages that I believe that should not be in there. > > Because the old package set will still be there, nobody should be disrupted > and meanwhile people can try/test the new approach. > > Any objections? I've looked into you fork already, looks very positive to me. Appreciate your work on it and also the in-depth background explanation in your blog. :) I am using mainly pip2nix and npm2nix in my projects to generate package sets, willing to switch to node2nix soonish. >From my perspective, I would even take a switch under the same name, even if >it would mean a few hazzles for me potentially to get things up and running >again. On the other side, esp. if people use it and get such a change as a >surprise, it can be negative, since they would be forces to switch fast or get >the old npm2nix available still. At least a fallback option to get the old >npm2nix easily would be good to have if we keep the same name for the new >thing. Cheers, Johannes ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Rok,
what about people who are already using previous solution? Why break their
workflows?
2016-07-05 7:36 GMT+01:00 Rok Garbas :
> +1 for just keeping the name npm2nix and bumping up the version.
>
> i'm not using it on any active project, but i'm going to in the near
> future.
>
>
>
> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug
> wrote:
> > Hi Sander,
> >
> > sorry for my very late response. I'll make this one brief as I am sadly
> on
> > my phone.
> >
> > I belong to one of those who tried your new npm2nix and in fact am
> already
> > using it regularly. I am very much in favor of having your
> re-engineeering2
> > branch replacing npm2nix as the de-facto node integration tool.
> >
> > I also definitely want to see the current set of auto-generated node
> > packages removed from nix. They are almost exclusively *totally*
> outdated.
> >
> > Thank you a lot for your continued efforts on this. Working with
> npm/node is
> > annoying but we are better off with your contributions.
> >
> > cheers,
> > Tobi
> >
> > On 22 Jun 2016, at 20:24, Sander van der Burg
> wrote:
> >
> > Hello Nix and Node.js users,
> >
> > I have been absent for a while in this discussion, but as far as I know
> the
> > state of the NPM packages in Nixpkgs is still quite bad and despite some
> > discussions on the mailing list we have not really come to any consensus
> > yet.
> >
> > As some of you may know, I have my own re-engineered version of npm2nix
> that
> > lives in a specific branch in my own personal fork
> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few
> months
> > ago, I did some major efforts in getting npm 3.x's behaviour supported,
> > which I have documented in this blog post:
> >
> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
> >
> > I have been using this reengineering2 branch for all my public and some
> of
> > my private projects since the beginning of this year, and for me it
> seems to
> > work quite well, despite the fact that some of npm 3.x's flat module
> > installation oddities are still not accurately supported yet.
> >
> > I also received a couple of reports from other people claiming that their
> > projects work and even encountered some people saying that it should
> replace
> > the current npm2nix. :)
> >
> > Obviously, I do not want to claim that my implementation is the perfect
> > solution as it (for example) is much slower than the vanilla npm2nix,
> and it
> > composes the entire set of dependencies in one derivation as opposed to
> > generating a Nix store path per NPM dependency. (I do this for a very
> good
> > reason. For more details, please read my blog post).
> >
> > Furthermore, I have also spoken to people that suggested completely
> > different kinds of approaches in getting NPM supported in a Nix
> environment.
> >
> > Something that I have not done yet is investigating whether this
> > reengineered solution could be a potential replacement for the NPM
> packages
> > set in Nixpkgs.
> >
> > Today, I have been working on an integration pattern, and the good news
> is:
> > it seems that I was able to generate Nix expressions for almost all
> packages
> > that are in pkgs/top-level/node-packages.json. The only exceptions were
> the
> > node-xmpp-* and bip-* packages, but some of them seem to have broken
> > dependencies, which is not npm2nix's fault.
> >
> > If we would proceed integrating, we have a number of practical
> implications:
> >
> > - I believe it is desired to have both Node.js 4.x and Node.js 5.x, 6.x
> > supported (I actually need all of them). To support all of these, we need
> > two different sets of generated Nix expressions. The former uses npm 2.x
> > with the classic dependency addressing approach and the latter uses npm
> 3.x
> > with flat module installations.
> > - I think most library packages should be removed from
> node-packages.json:
> > as explained in my blog post: how a package gets composed and to which
> > version a range resolve depends on the state of the includer. When
> somebody
> > wants their own NPM project to be deployed, he should use npm2nix
> directly
> > on package.json, and not refer to any NPM libraries in Nixpkgs.
> > - Some NPM packages must be overridden to provide native dependencies.
> The
> > mechanisms that the reengineering2 branch use are different. It would
> > probably take a bit of effort to get these migrated.
> >
> > For example, this is how I override the webdrvr package to provide
> phantomjs
> > and the Selenium webdriver:
> >
> > {pkgs, system}:
> >
> > let
> > nodePackages = import ./composition-v4.nix {
> > inherit pkgs system;
> > };
> > in
> > nodePackages // {
> > webdrvr = nodePackages.webdrvr.override (oldAttrs: {
> > buildInputs = oldAttrs.buildInputs ++ [ pkgs.phantomjs ];
> >
> > preRebuild = ''
> > mkdir $TMPDIR/webdrvr
> >
> > ln -s ${pkgs.fetchurl {
> > url =
> > "
> https://selenium-release.storage.goog
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
+1 for just keeping the name npm2nix and bumping up the version.
i'm not using it on any active project, but i'm going to in the near future.
On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug wrote:
> Hi Sander,
>
> sorry for my very late response. I'll make this one brief as I am sadly on
> my phone.
>
> I belong to one of those who tried your new npm2nix and in fact am already
> using it regularly. I am very much in favor of having your re-engineeering2
> branch replacing npm2nix as the de-facto node integration tool.
>
> I also definitely want to see the current set of auto-generated node
> packages removed from nix. They are almost exclusively *totally* outdated.
>
> Thank you a lot for your continued efforts on this. Working with npm/node is
> annoying but we are better off with your contributions.
>
> cheers,
> Tobi
>
> On 22 Jun 2016, at 20:24, Sander van der Burg wrote:
>
> Hello Nix and Node.js users,
>
> I have been absent for a while in this discussion, but as far as I know the
> state of the NPM packages in Nixpkgs is still quite bad and despite some
> discussions on the mailing list we have not really come to any consensus
> yet.
>
> As some of you may know, I have my own re-engineered version of npm2nix that
> lives in a specific branch in my own personal fork
> (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few months
> ago, I did some major efforts in getting npm 3.x's behaviour supported,
> which I have documented in this blog post:
> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
>
> I have been using this reengineering2 branch for all my public and some of
> my private projects since the beginning of this year, and for me it seems to
> work quite well, despite the fact that some of npm 3.x's flat module
> installation oddities are still not accurately supported yet.
>
> I also received a couple of reports from other people claiming that their
> projects work and even encountered some people saying that it should replace
> the current npm2nix. :)
>
> Obviously, I do not want to claim that my implementation is the perfect
> solution as it (for example) is much slower than the vanilla npm2nix, and it
> composes the entire set of dependencies in one derivation as opposed to
> generating a Nix store path per NPM dependency. (I do this for a very good
> reason. For more details, please read my blog post).
>
> Furthermore, I have also spoken to people that suggested completely
> different kinds of approaches in getting NPM supported in a Nix environment.
>
> Something that I have not done yet is investigating whether this
> reengineered solution could be a potential replacement for the NPM packages
> set in Nixpkgs.
>
> Today, I have been working on an integration pattern, and the good news is:
> it seems that I was able to generate Nix expressions for almost all packages
> that are in pkgs/top-level/node-packages.json. The only exceptions were the
> node-xmpp-* and bip-* packages, but some of them seem to have broken
> dependencies, which is not npm2nix's fault.
>
> If we would proceed integrating, we have a number of practical implications:
>
> - I believe it is desired to have both Node.js 4.x and Node.js 5.x, 6.x
> supported (I actually need all of them). To support all of these, we need
> two different sets of generated Nix expressions. The former uses npm 2.x
> with the classic dependency addressing approach and the latter uses npm 3.x
> with flat module installations.
> - I think most library packages should be removed from node-packages.json:
> as explained in my blog post: how a package gets composed and to which
> version a range resolve depends on the state of the includer. When somebody
> wants their own NPM project to be deployed, he should use npm2nix directly
> on package.json, and not refer to any NPM libraries in Nixpkgs.
> - Some NPM packages must be overridden to provide native dependencies. The
> mechanisms that the reengineering2 branch use are different. It would
> probably take a bit of effort to get these migrated.
>
> For example, this is how I override the webdrvr package to provide phantomjs
> and the Selenium webdriver:
>
> {pkgs, system}:
>
> let
> nodePackages = import ./composition-v4.nix {
> inherit pkgs system;
> };
> in
> nodePackages // {
> webdrvr = nodePackages.webdrvr.override (oldAttrs: {
> buildInputs = oldAttrs.buildInputs ++ [ pkgs.phantomjs ];
>
> preRebuild = ''
> mkdir $TMPDIR/webdrvr
>
> ln -s ${pkgs.fetchurl {
> url =
> "https://selenium-release.storage.googleapis.com/2.43/selenium-server-standalone-2.43.1.jar";;
> sha1 = "ef1b5f8ae9c99332f99ba8794988a1d5b974d27b";
> }} $TMPDIR/webdrvr/selenium-server-standalone-2.43.1.jar
> ln -s ${pkgs.fetchurl {
> url =
> "http://chromedriver.storage.googleapis.com/2.10/chromedriver_linux64.zip";;
> sha1 = "26220f7e43ee3c0d714860db61c4d0ecc9bb3d89";
> }} $TMPDIR/webdrvr/ch
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Hi Sander,
sorry for my very late response. I'll make this one brief as I am sadly on my
phone.
I belong to one of those who tried your new npm2nix and in fact am already
using it regularly. I am very much in favor of having your re-engineeering2
branch replacing npm2nix as the de-facto node integration tool.
I also definitely want to see the current set of auto-generated node packages
removed from nix. They are almost exclusively *totally* outdated.
Thank you a lot for your continued efforts on this. Working with npm/node is
annoying but we are better off with your contributions.
cheers,
Tobi
> On 22 Jun 2016, at 20:24, Sander van der Burg wrote:
>
> Hello Nix and Node.js users,
>
> I have been absent for a while in this discussion, but as far as I know the
> state of the NPM packages in Nixpkgs is still quite bad and despite some
> discussions on the mailing list we have not really come to any consensus yet.
>
> As some of you may know, I have my own re-engineered version of npm2nix that
> lives in a specific branch in my own personal fork
> (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few months
> ago, I did some major efforts in getting npm 3.x's behaviour supported, which
> I have documented in this blog post:
> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
>
> I have been using this reengineering2 branch for all my public and some of my
> private projects since the beginning of this year, and for me it seems to
> work quite well, despite the fact that some of npm 3.x's flat module
> installation oddities are still not accurately supported yet.
>
> I also received a couple of reports from other people claiming that their
> projects work and even encountered some people saying that it should replace
> the current npm2nix. :)
>
> Obviously, I do not want to claim that my implementation is the perfect
> solution as it (for example) is much slower than the vanilla npm2nix, and it
> composes the entire set of dependencies in one derivation as opposed to
> generating a Nix store path per NPM dependency. (I do this for a very good
> reason. For more details, please read my blog post).
>
> Furthermore, I have also spoken to people that suggested completely different
> kinds of approaches in getting NPM supported in a Nix environment.
>
> Something that I have not done yet is investigating whether this reengineered
> solution could be a potential replacement for the NPM packages set in Nixpkgs.
>
> Today, I have been working on an integration pattern, and the good news is:
> it seems that I was able to generate Nix expressions for almost all packages
> that are in pkgs/top-level/node-packages.json. The only exceptions were the
> node-xmpp-* and bip-* packages, but some of them seem to have broken
> dependencies, which is not npm2nix's fault.
>
> If we would proceed integrating, we have a number of practical implications:
>
> - I believe it is desired to have both Node.js 4.x and Node.js 5.x, 6.x
> supported (I actually need all of them). To support all of these, we need two
> different sets of generated Nix expressions. The former uses npm 2.x with the
> classic dependency addressing approach and the latter uses npm 3.x with flat
> module installations.
> - I think most library packages should be removed from node-packages.json: as
> explained in my blog post: how a package gets composed and to which version a
> range resolve depends on the state of the includer. When somebody wants their
> own NPM project to be deployed, he should use npm2nix directly on
> package.json, and not refer to any NPM libraries in Nixpkgs.
> - Some NPM packages must be overridden to provide native dependencies. The
> mechanisms that the reengineering2 branch use are different. It would
> probably take a bit of effort to get these migrated.
>
> For example, this is how I override the webdrvr package to provide phantomjs
> and the Selenium webdriver:
>
> {pkgs, system}:
>
> let
> nodePackages = import ./composition-v4.nix {
> inherit pkgs system;
> };
> in
> nodePackages // {
> webdrvr = nodePackages.webdrvr.override (oldAttrs: {
> buildInputs = oldAttrs.buildInputs ++ [ pkgs.phantomjs ];
>
> preRebuild = ''
> mkdir $TMPDIR/webdrvr
>
> ln -s ${pkgs.fetchurl {
> url =
> "https://selenium-release.storage.googleapis.com/2.43/selenium-server-standalone-2.43.1.jar";;
> sha1 = "ef1b5f8ae9c99332f99ba8794988a1d5b974d27b";
> }} $TMPDIR/webdrvr/selenium-server-standalone-2.43.1.jar
> ln -s ${pkgs.fetchurl {
> url =
> "http://chromedriver.storage.googleapis.com/2.10/chromedriver_linux64.zip";;
> sha1 = "26220f7e43ee3c0d714860db61c4d0ecc9bb3d89";
> }} $TMPDIR/webdrvr/chromedriver_linux64.zip
>
> '';
> });
> }
>
>
> Although we have some practical issues, I think none of them would impose a
> serious problem.
>
> Then
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
2016-07-04 16:34 GMT+01:00 Sander van der Burg : > So far only one response... > > I'm planning to implement the most pragmatic approach very soon -- due to > lack of a better/cooler name I'll rename my fork of npm2nix to node2nix. > > Moreover, I will add a second attribute set to Nixpkgs allowing people to > deploy packages that have been generated with node2nix. Also, I will take > the original node-packages.json as a basis, but I will remove the library > packages that I believe that should not be in there. > > Because the old package set will still be there, nobody should be > disrupted and meanwhile people can try/test the new approach. > > Any objections? > Go for it! :-) Btw, I'm not sure I'm the only one, but I usually use per project dependencies. In general I think keeping this autogenerated stuff in repo is not the way to go IMHO. Most of the time I use nix packages as a building tools but I'm not using requirements from it. I like all the "generators" to generate dependencies for exactly my project, in that case it won't break stuff even if nixpkgs will move forward. For example I would never relay on django version from nix as I want this to be specific one and I want to change it when the project is ready not at random time after some upgrade. So I would definitely use node2nix to generate dependencies for my projects, thank you Sander! Tom > > Regards, > > Sander > > > On Wed, Jun 22, 2016 at 11:39 PM, Tomasz Czyż > wrote: > >> Hi Sander, >> >> awesome stuff. >> >> I would say, change name to something like node2nix and let's merge the >> thing as it looks very good. >> >> Pros: >> - backward compatibility >> - process of merging will be lot faster (IMHO) as it will not collide >> with anything and probably this will limit non productive discussions out >> >> Big thanks, >> Tom >> >> 2016-06-22 19:24 GMT+01:00 Sander van der Burg : >> >>> Hello Nix and Node.js users, >>> >>> I have been absent for a while in this discussion, but as far as I know >>> the state of the NPM packages in Nixpkgs is still quite bad and despite >>> some discussions on the mailing list we have not really come to any >>> consensus yet. >>> >>> As some of you may know, I have my own re-engineered version of npm2nix >>> that lives in a specific branch in my own personal fork ( >>> https://github.com/svanderburg/npm2nix/tree/reengineering2). A few >>> months ago, I did some major efforts in getting npm 3.x's behaviour >>> supported, which I have documented in this blog post: >>> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >>> >>> I have been using this reengineering2 branch for all my public and some >>> of my private projects since the beginning of this year, and for me it >>> seems to work quite well, despite the fact that some of npm 3.x's flat >>> module installation oddities are still not accurately supported yet. >>> >>> I also received a couple of reports from other people claiming that >>> their projects work and even encountered some people saying that it should >>> replace the current npm2nix. :) >>> >>> Obviously, I do not want to claim that my implementation is the perfect >>> solution as it (for example) is much slower than the vanilla npm2nix, and >>> it composes the entire set of dependencies in one derivation as opposed to >>> generating a Nix store path per NPM dependency. (I do this for a very good >>> reason. For more details, please read my blog post). >>> >>> Furthermore, I have also spoken to people that suggested completely >>> different kinds of approaches in getting NPM supported in a Nix environment. >>> >>> Something that I have not done yet is investigating whether this >>> reengineered solution could be a potential replacement for the NPM packages >>> set in Nixpkgs. >>> >>> Today, I have been working on an integration pattern, and the good news >>> is: it seems that I was able to generate Nix expressions for almost all >>> packages that are in pkgs/top-level/node-packages.json. The only exceptions >>> were the node-xmpp-* and bip-* packages, but some of them seem to have >>> broken dependencies, which is not npm2nix's fault. >>> >>> If we would proceed integrating, we have a number of practical >>> implications: >>> >>> - I believe it is desired to have both Node.js 4.x and Node.js 5.x, 6.x >>> supported (I actually need all of them). To support all of these, we need >>> two different sets of generated Nix expressions. The former uses npm 2.x >>> with the classic dependency addressing approach and the latter uses npm 3.x >>> with flat module installations. >>> - I think most library packages should be removed from >>> node-packages.json: as explained in my blog post: how a package gets >>> composed and to which version a range resolve depends on the state of the >>> includer. When somebody wants their own NPM project to be deployed, he >>> should use npm2nix directly on package.json, and not refer to any NPM >>> libraries in Nixpkgs. >>> -
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
So far only one response...
I'm planning to implement the most pragmatic approach very soon -- due to
lack of a better/cooler name I'll rename my fork of npm2nix to node2nix.
Moreover, I will add a second attribute set to Nixpkgs allowing people to
deploy packages that have been generated with node2nix. Also, I will take
the original node-packages.json as a basis, but I will remove the library
packages that I believe that should not be in there.
Because the old package set will still be there, nobody should be disrupted
and meanwhile people can try/test the new approach.
Any objections?
Regards,
Sander
On Wed, Jun 22, 2016 at 11:39 PM, Tomasz Czyż wrote:
> Hi Sander,
>
> awesome stuff.
>
> I would say, change name to something like node2nix and let's merge the
> thing as it looks very good.
>
> Pros:
> - backward compatibility
> - process of merging will be lot faster (IMHO) as it will not collide with
> anything and probably this will limit non productive discussions out
>
> Big thanks,
> Tom
>
> 2016-06-22 19:24 GMT+01:00 Sander van der Burg :
>
>> Hello Nix and Node.js users,
>>
>> I have been absent for a while in this discussion, but as far as I know
>> the state of the NPM packages in Nixpkgs is still quite bad and despite
>> some discussions on the mailing list we have not really come to any
>> consensus yet.
>>
>> As some of you may know, I have my own re-engineered version of npm2nix
>> that lives in a specific branch in my own personal fork (
>> https://github.com/svanderburg/npm2nix/tree/reengineering2). A few
>> months ago, I did some major efforts in getting npm 3.x's behaviour
>> supported, which I have documented in this blog post:
>> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
>>
>> I have been using this reengineering2 branch for all my public and some
>> of my private projects since the beginning of this year, and for me it
>> seems to work quite well, despite the fact that some of npm 3.x's flat
>> module installation oddities are still not accurately supported yet.
>>
>> I also received a couple of reports from other people claiming that their
>> projects work and even encountered some people saying that it should
>> replace the current npm2nix. :)
>>
>> Obviously, I do not want to claim that my implementation is the perfect
>> solution as it (for example) is much slower than the vanilla npm2nix, and
>> it composes the entire set of dependencies in one derivation as opposed to
>> generating a Nix store path per NPM dependency. (I do this for a very good
>> reason. For more details, please read my blog post).
>>
>> Furthermore, I have also spoken to people that suggested completely
>> different kinds of approaches in getting NPM supported in a Nix environment.
>>
>> Something that I have not done yet is investigating whether this
>> reengineered solution could be a potential replacement for the NPM packages
>> set in Nixpkgs.
>>
>> Today, I have been working on an integration pattern, and the good news
>> is: it seems that I was able to generate Nix expressions for almost all
>> packages that are in pkgs/top-level/node-packages.json. The only exceptions
>> were the node-xmpp-* and bip-* packages, but some of them seem to have
>> broken dependencies, which is not npm2nix's fault.
>>
>> If we would proceed integrating, we have a number of practical
>> implications:
>>
>> - I believe it is desired to have both Node.js 4.x and Node.js 5.x, 6.x
>> supported (I actually need all of them). To support all of these, we need
>> two different sets of generated Nix expressions. The former uses npm 2.x
>> with the classic dependency addressing approach and the latter uses npm 3.x
>> with flat module installations.
>> - I think most library packages should be removed from
>> node-packages.json: as explained in my blog post: how a package gets
>> composed and to which version a range resolve depends on the state of the
>> includer. When somebody wants their own NPM project to be deployed, he
>> should use npm2nix directly on package.json, and not refer to any NPM
>> libraries in Nixpkgs.
>> - Some NPM packages must be overridden to provide native dependencies.
>> The mechanisms that the reengineering2 branch use are different. It would
>> probably take a bit of effort to get these migrated.
>>
>> For example, this is how I override the webdrvr package to provide
>> phantomjs and the Selenium webdriver:
>>
>> {pkgs, system}:
>>
>> let
>> nodePackages = import ./composition-v4.nix {
>> inherit pkgs system;
>> };
>> in
>> nodePackages // {
>> webdrvr = nodePackages.webdrvr.override (oldAttrs: {
>> buildInputs = oldAttrs.buildInputs ++ [ pkgs.phantomjs ];
>>
>> preRebuild = ''
>> mkdir $TMPDIR/webdrvr
>>
>> ln -s ${pkgs.fetchurl {
>> url = "
>> https://selenium-release.storage.googleapis.com/2.43/selenium-server-standalone-2.43.1.jar
>> ";
>> sha1 = "ef1b5f8ae9c99332f99ba8794988a1d5b974d27b";
>> }} $T
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Hi Sander,
awesome stuff.
I would say, change name to something like node2nix and let's merge the
thing as it looks very good.
Pros:
- backward compatibility
- process of merging will be lot faster (IMHO) as it will not collide with
anything and probably this will limit non productive discussions out
Big thanks,
Tom
2016-06-22 19:24 GMT+01:00 Sander van der Burg :
> Hello Nix and Node.js users,
>
> I have been absent for a while in this discussion, but as far as I know
> the state of the NPM packages in Nixpkgs is still quite bad and despite
> some discussions on the mailing list we have not really come to any
> consensus yet.
>
> As some of you may know, I have my own re-engineered version of npm2nix
> that lives in a specific branch in my own personal fork (
> https://github.com/svanderburg/npm2nix/tree/reengineering2). A few months
> ago, I did some major efforts in getting npm 3.x's behaviour supported,
> which I have documented in this blog post:
> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
>
> I have been using this reengineering2 branch for all my public and some of
> my private projects since the beginning of this year, and for me it seems
> to work quite well, despite the fact that some of npm 3.x's flat module
> installation oddities are still not accurately supported yet.
>
> I also received a couple of reports from other people claiming that their
> projects work and even encountered some people saying that it should
> replace the current npm2nix. :)
>
> Obviously, I do not want to claim that my implementation is the perfect
> solution as it (for example) is much slower than the vanilla npm2nix, and
> it composes the entire set of dependencies in one derivation as opposed to
> generating a Nix store path per NPM dependency. (I do this for a very good
> reason. For more details, please read my blog post).
>
> Furthermore, I have also spoken to people that suggested completely
> different kinds of approaches in getting NPM supported in a Nix environment.
>
> Something that I have not done yet is investigating whether this
> reengineered solution could be a potential replacement for the NPM packages
> set in Nixpkgs.
>
> Today, I have been working on an integration pattern, and the good news
> is: it seems that I was able to generate Nix expressions for almost all
> packages that are in pkgs/top-level/node-packages.json. The only exceptions
> were the node-xmpp-* and bip-* packages, but some of them seem to have
> broken dependencies, which is not npm2nix's fault.
>
> If we would proceed integrating, we have a number of practical
> implications:
>
> - I believe it is desired to have both Node.js 4.x and Node.js 5.x, 6.x
> supported (I actually need all of them). To support all of these, we need
> two different sets of generated Nix expressions. The former uses npm 2.x
> with the classic dependency addressing approach and the latter uses npm 3.x
> with flat module installations.
> - I think most library packages should be removed from node-packages.json:
> as explained in my blog post: how a package gets composed and to which
> version a range resolve depends on the state of the includer. When somebody
> wants their own NPM project to be deployed, he should use npm2nix directly
> on package.json, and not refer to any NPM libraries in Nixpkgs.
> - Some NPM packages must be overridden to provide native dependencies. The
> mechanisms that the reengineering2 branch use are different. It would
> probably take a bit of effort to get these migrated.
>
> For example, this is how I override the webdrvr package to provide
> phantomjs and the Selenium webdriver:
>
> {pkgs, system}:
>
> let
> nodePackages = import ./composition-v4.nix {
> inherit pkgs system;
> };
> in
> nodePackages // {
> webdrvr = nodePackages.webdrvr.override (oldAttrs: {
> buildInputs = oldAttrs.buildInputs ++ [ pkgs.phantomjs ];
>
> preRebuild = ''
> mkdir $TMPDIR/webdrvr
>
> ln -s ${pkgs.fetchurl {
> url = "
> https://selenium-release.storage.googleapis.com/2.43/selenium-server-standalone-2.43.1.jar
> ";
> sha1 = "ef1b5f8ae9c99332f99ba8794988a1d5b974d27b";
> }} $TMPDIR/webdrvr/selenium-server-standalone-2.43.1.jar
> ln -s ${pkgs.fetchurl {
> url = "
> http://chromedriver.storage.googleapis.com/2.10/chromedriver_linux64.zip";;
> sha1 = "26220f7e43ee3c0d714860db61c4d0ecc9bb3d89";
> }} $TMPDIR/webdrvr/chromedriver_linux64.zip
>
> '';
> });
> }
>
>
> Although we have some practical issues, I think none of them would impose
> a serious problem.
>
> Then about npm2nix itself: Obviously, we could say that my version
> replaces the upstream npm2nix and gets "blessed" into the new "official"
> version, but I don't know whether everybody likes it.
>
> Alternatively, we could be a bit more pragmatic: I stop calling my
> reengineering2 version npm2nix, I give it a different name and I release it
> as a different
