[Nix-dev] On npm2nix and the NPM package set in Nixpkgs

[Tomasz Czyż]

2016-07-13 22:13 GMT+01:00 Wout Mertens <wout.mertens at gmail.com>:

> 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 <svanderburg at 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 <ab at fmap.me> 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 at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>


-- 
Tomasz Czyż
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160714/cbaf9058/attachment.html>