Re: [Nix-dev] yet another npm2nix reengineering attempt

2016-03-07 Thread Wout Mertens 
Great job Sander!

Some thoughts:

   - Node 5 layout is Node 4 compatible, so why not use only that?
   - You can symlink the first level of modules instead of the modules
   themselves to avoid the commonjs derefence thing. So a combination of
   modules becomes a shallow copy.
   - npm2nix doesn't have to support cycles and conflicting versions.
   Having a local node_modules in the project for those pathological cases is
   always an option. Better to only support clean and sane dependency graphs.
   - npm2nix doesn't have to generate the same output as npm. It just needs
   to generate something that matches the package.json declarations when
   loaded into Node…

I think that if you limit what npm2nix does, it will be a lot easier to
handle…

Wout.

On Tue, Mar 1, 2016 at 3:12 PM Sander van der Burg 
wrote:

> It's stateful because the packages that end up in a dependency's
> node_modules/ folder depend on the packages that have been stored in any of
> the includer's (parent directory's) node_modules/ folders. When a
> dependency has been encountered a second time (that fits within a package's
> version range), NPM will not include it again.
>
> For example: if a package would declare a dependency (such as: "optparse":
> ">= 1.0.3") and any of the parent node_modules/ folders would provide
> version 1.0.5, then optparse/ will not be deployed again in the package's
> private node_modules/ folder. Instead, it will be left out and the package
> binds to the version of the parent.
>
> Second, with npm 3.x's flat module installations, we must move packages as
> high as possible in the nested node_modules/ hierarchy, until a conflict
> has been encountered.
>
> On Tue, Mar 1, 2016 at 1:53 PM, Shea Levy  wrote:
>
>> "including NPM dependencies is stateful" how so? Having separate
>> derivations symlinked in would give you sharing, no?
>>
>> On 2016-03-01 08:15, Sander van der Burg wrote:
>> > Hi,
>> >
>> > I don't know how many of you have noticed my latest blog post
>> >
>> > (
>> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
>> > [1]), but I did yet another reengineering attempt for npm2nix. Its
>> > main objective is to also support npm 3.x's flat module installations
>> > (npm 3.x comes with Node.js 5.x).
>> >
>> > In the second reengineered version, I compute the entire dependency
>> > graph ahead of time and build the entire set of dependencies in one
>> > derivation -- there is no good reason to make them individual Nix
>> > packages, because including NPM dependencies is stateful.
>> >
>> > The new reengineered version supports both Node.js 4.x and 5.x. By
>> > default, it generates expressions for 4.x (I made this the default,
>> > since 4.x is the LTS release):
>> >
>> > $ npm2nix
>> >
>> > Adding the -5 parameter causes it to generate expressions for Node.js
>> > 5.x:
>> >
>> > $ npm2nix -5
>> >
>> > The code lives in the same repository as the old reengineering
>> > version, but in a different branch:
>> >
>> > https://github.com/svanderburg/npm2nix/tree/reengineering2 [2]
>> >
>> > There is a README.md file that describes how to use it and
>> > demonstrates a few common use cases.
>> >
>> > The flat module installation works for many of my packages but it is
>> > still not 100% perfect. My blog post describes some of its
>> > limitations.
>> >
>> > Anyway, I'm announcing this new version so that I can gather
>> > feedback. Maybe this new implementation is not what people are
>> > actually looking for, but I'm eating my own dogfood with it now and
>> > for all my own projects it works fine.
>> >
>> > Regards,
>> >
>> > Sander
>> >
>> >
>> >
>> > Links:
>> > --
>> > [1]
>> >
>> >
>> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
>> > [2] https://github.com/svanderburg/npm2nix/tree/reengineering2
>> >
>> > ___
>> > 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
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Open source team messaging: mattermost

2016-03-07 Thread Matej Cotman 
Do we even need to have this talk? I thought till now that every opensource
developer has to be in communication on freenode, there are just so many
projects on it. Btw i am using irc through browser- weechat+glowing bear,
easy setup for opensource dev, and I am using slack for work and its
terible, history is limited and our router is giving up with 15devices,
half of them has slack in browser and every one of them has over 100
simultanious connections open (when someone closes slack, number of
connections go down for that user)

On Tue, Mar 8, 2016, 07:30 Wout Mertens  wrote:

> After having used Slack and Discord for a while, I can tell you that
> having the recent chat log available with a quick scroll up is very handy.
> Conversations can continue over a longer period of time.
>
> With IRC, you have to open your client, fire off your question a few times
> and hope that someone will know the answer eventually. I can't have IRC
> open at work all day.
>
>
> On Fri, Mar 4, 2016 at 12:55 AM Profpatsch  wrote:
>
>> On 16-03-01 11:46pm, Teo Klestrup Röijezon wrote:
>> > Plain IRC sucks.
>>
>> It’s true, but it f* works.
>>
>> Especially for developers, devs who can’t configure an IRC client?
>> Are those people devs?
>>
>> But I know the pain.
>>
>> Hm, we even use IRC as main communication tool in our Hackerspace,
>> and so far even non-tech people managed to get a basic setup running.
>> Maybe no bouncer, but that’s not required strictly speaking.
>>
>> --
>> Proudly written in Mutt with Vim on NixOS.
>> Q: Why is this email five sentences or less?
>> A: http://five.sentenc.es
>> May take up to five days to read your message. If it’s urgent, call me.
>>
> --
>
> Wout.
> (typed on mobile, excuse terseness)
> ___
> 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] Open source team messaging: mattermost

2016-03-07 Thread Wout Mertens 
After having used Slack and Discord for a while, I can tell you that having
the recent chat log available with a quick scroll up is very handy.
Conversations can continue over a longer period of time.

With IRC, you have to open your client, fire off your question a few times
and hope that someone will know the answer eventually. I can't have IRC
open at work all day.


On Fri, Mar 4, 2016 at 12:55 AM Profpatsch  wrote:

> On 16-03-01 11:46pm, Teo Klestrup Röijezon wrote:
> > Plain IRC sucks.
>
> It’s true, but it f* works.
>
> Especially for developers, devs who can’t configure an IRC client?
> Are those people devs?
>
> But I know the pain.
>
> Hm, we even use IRC as main communication tool in our Hackerspace,
> and so far even non-tech people managed to get a basic setup running.
> Maybe no bouncer, but that’s not required strictly speaking.
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Import remote packages in NixOps/NixOS

2016-03-07 Thread Eric Sagnes 
It is possible to import foreign modules in NixOps by doing:

```
{
  network.description = "Web server";

  webserver = { config, pkgs, ... }:
let
  myModuleSrc = (import  {}).fetchFromGitHub {
  owner  = "me";
  repo   = "myModule";
  rev= "v1.0";
  sha256 = "";
  };
in
{ 
  imports = [ "${myModuleSrc}/module.nix" ]; 
  services.myModule.enable = true;
};
}
```

Presupposing that the remote package provides a nix build expression,
is it possible to directly import it in a similar way?
Pseudo code that is not working:

```
{
  network.description = "Web server";

  webserver = { config, pkgs, ... }:
let
  myPackageSrc = (import  {}).fetchFromGitHub {
  owner  = "me";
  repo   = "myPackage";
  rev= "v1.0";
  sha256 = "";
  };
in
{ 
  environment.systemPackages = [
(import "${myPackageSrc}/release.nix")
  ];

};
}
```

(The above complains about coercing a function to a string.)

Cheers,
-- 
Eric Sagnes
サニエ エリック
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 16.03 channel available for testing

2016-03-07 Thread Vladimír Čunát 
On 03/07/2016 06:28 PM, Vladimír Čunát wrote:
> It seems the URL needed is https://nixos.org/channels/nixos-16.03-beta

Ah, I'm sorry, I didn't update this e-mail directory :-)



smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 16.03 channel available for testing

2016-03-07 Thread Vladimír Čunát 
On 03/07/2016 01:36 PM, Domen Kožar wrote:
> $ nix-channel --add https://nixos.org/channels/nixos-16.03 nixos

It seems the URL needed is https://nixos.org/channels/nixos-16.03-beta
BTW, (preliminary) release notes are e.g. at:
https://nixos.org/releases/nixos/16.03-beta/nixos-16.03.30.2068621/manual/release-notes.html#sec-release-16.03

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] JAVA_HOME and other environment variables

2016-03-07 Thread zimbatm 
If the given programs are packaged with nix then it shouldn't be an issue
but I agree that for starting random programs it's not ideal. Maybe the
solution it to make it dead easy to wrap a Java program in a derivation ?

On Mon, 7 Mar 2016 at 01:51 Svein Ove Aas  wrote:

> That's effectively what happens already, if you use nix-shell.
>
> I'm concerned mostly about users who don't know to do that. Someone trying
> to run a script from a different brand of unix, for example.
>
> In theory, if there is a java binary on the PATH, there should also be a
> JAVA_HOME. That's Oracle's take on this, but... well, I prefer Nix to have
> as few surprises as possible.
>
> On Sun, Mar 6, 2016 at 8:12 PM zimbatm  wrote:
>
>> What if the JRE(s) also included a `java-env.sh` that can be sourced ?
>> Then it's easy to build wrappers that source it dynamically.
>>
>> On Sat, 5 Mar 2016 at 17:34 Svein Ove Aas  wrote:
>>
>>> Context: https://github.com/NixOS/nixpkgs/issues/13653
>>>
>>> There are a few packages which can't be considered properly installed
>>> (and usable) without setting environment variables, this example being the
>>> Java development kit.
>>>
>>> Some Java-based tools need to know where to find the JDK. The way they
>>> do this is by looking at the JAVA_HOME environment variable. That is...
>>> currently, it isn't set at all, unless you use nix-shell or an equivalent
>>> mechanism.
>>>
>>> I've thought of a couple of solutions, but would welcome other
>>> suggestions. In no particular order...
>>>
>>> (The problem is not restricted to just JAVA_HOME.)
>>>
>>> - Wrapping the the JDK binaries with makeWrapper.
>>>   This is a non-starter, as it's common to use JAVA_HOME in scripts.
>>>
>>> - JAVA_HOME is set in the JDK's setup-hook. We can source that file on
>>> shell startup.
>>>   This works well for nix-shell, and is the approach I've chosen to take
>>> globally for a temporary fix. Unfortunately, it is in a sense even worse
>>> than the status quo. Since this produces a pointer into /nix/store, the
>>> value of JAVA_HOME in a running shell can become invalid because the JDK in
>>> question is GC'd (!), or superseded by a newer one *without* being deleted
>>> (!!).
>>>
>>> - Adding another directory under /run, containing symlinks that we can
>>> mutate.
>>>   Has the obvious problem of impurity, but we're talking about system
>>> (or user) profiles; they're already impure, in the same sense. I don't see
>>> any technical issues here, but that doesn't mean there aren't any. I'm not
>>> sure how to implement it, or even whether I should.
>>>   We'd have "JAVA_HOME=/run/env/JAVA_HOME", or so.
>>>
>>> One further concern...
>>>
>>> - Right now, the only way to install Java system-wide is to put it in
>>> environment.systemPackages. Or using nix-env. Either way, JAVA_HOME
>>> wouldn't get set; this is true even with that PR. I've been trying to think
>>> of ways to fix this, but I have no idea how. Send help!
>>>   As a result, even if I add programs.java to NixOS, it doesn't help
>>> anyone who's got the problem right now.
>>>
>>> 
>>>
>>> I'd like to implement a general solution for all such situations,
>>> ideally one that would get merged. Rant over, though. Thoughts?
>>>
>> ___
>>> 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] NixOS 16.03 channel available for testing

2016-03-07 Thread Eelco Dolstra 
Hi,

On 07/03/16 16:29, Domen Kožar wrote:

> Maybe the version should be 16.03-beta?

Good idea, done.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 16.03 channel available for testing

2016-03-07 Thread Domen Kožar 
Maybe the version should be 16.03-beta?

On Mon, 7 Mar 2016, 15:18 Eelco Dolstra, 
wrote:

> Hi,
>
> On 07/03/16 13:36, Domen Kožar wrote:
>
> > 16.03 release channel has been generated, so you're all welcome to test
> and
> > report any issues:
> >
> > $ nix-channel --add https://nixos.org/channels/nixos-16.03 nixos
>
> I've renamed this channel to
> https://nixos.org/channels/nixos-16.03-testing to
> prevent people from mistaking this for a stable release.
>
> --
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> ___
> 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] NixOS 16.03 channel available for testing

2016-03-07 Thread Eelco Dolstra 
Hi,

On 07/03/16 13:36, Domen Kožar wrote:

> 16.03 release channel has been generated, so you're all welcome to test and
> report any issues:
> 
> $ nix-channel --add https://nixos.org/channels/nixos-16.03 nixos

I've renamed this channel to https://nixos.org/channels/nixos-16.03-testing to
prevent people from mistaking this for a stable release.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] NixOS 16.03 channel available for testing

2016-03-07 Thread Domen Kožar 
Hi all,

16.03 release channel has been generated, so you're all welcome to test and
report any issues:

$ nix-channel --add https://nixos.org/channels/nixos-16.03 nixos
$ nixos-rebuild switch --upgrade

Domen
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How to delete old generations and GC them, without GCing anything else?

2016-03-07 Thread Matthias Beyer 
Well it seems that making shell environments persistent is a more valuable
idea...

Thanks for your input, though!

On 06-03-2016 16:34:16, Vladimír Čunát wrote:
> On 03/06/2016 02:14 PM, Kosyrev Serge wrote:
> > Vladimír Čunát  writes:
> >> On 03/06/2016 01:10 PM, Matthias Beyer wrote:
> >>> I want to remove old system generations and GC the packages, _without_ 
> >>> removing
> >>> anything else but these generations and their packages.
> >>
> >> I would `nix-store --gc --print-dead` before and after deleting the
> >> generations, and then I would use `comm` to compute the difference and
> >> remove it by `nix-store --gc --delete`.
> > 
> > How does this differ from deleting
> > 
> >   /nix/var/nix/gcroots/profiles/system/system-{old,old,old,old}-link
> > 
> > and then running `nix-store --gc`?
> 
> It differs by not deleting stuff that was deletable before removing
> those system generations. That's what I assume was wanted by "...
> _without_ removing anything else but these generations and their packages."
> 
> --Vladimir
> 
> 



-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev