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ż <tomasz.c...@gmail.com> wrote: > 2016-07-13 22:13 GMT+01:00 Wout Mertens <wout.mert...@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 < >> 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 <a...@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@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
