Re: [Nix-dev] [erlang-questions] Erlang Package Manager

[stewart mackenzie]

On 15 Feb 2016 14:12, "Roger Qiu"  wrote:
> Having all that in nixpkgs might make it quite bloated.

Nix is a lazy language, nixpkgs repo size is a non-issue, save for cloning.

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

Re: [Nix-dev] [erlang-questions] Erlang Package Manager

[Roger Qiu]

Hey Gleb,

Thanks for the explanation. That makes sense, although I'm thinking of 
scalability, in terms of when other languages come around to Nix. Having 
all that in nixpkgs might make it quite bloated.


However the problem with cross channel dependencies is an interesting 
one, I suppose this problem needs to be fixed first.


Thanks,
Roger

On 15/02/2016 5:10 PM, Gleb Peregud wrote:


Hey Roger

Adding Eric, since he did a lot of work here too.

Few things. I'd like Erlang packages to be integrated into nixpkgs, so 
that they can have native dependencies. There's no package manager out 
there for Erlang which both has good coverage for Erlang packages and 
supports specifying native dependencies. Won't putting them into 
separate channel make it harder to do the latter? This is my first Nix 
project, so I'm not yet fully familiar with it.


For now it was not a problem to get things merged into nixpkgs, so I 
have nothing to complain here. There are indeed few Erlang users in 
Nix community, so I was getting some help. Existing infrastructure did 
help finding some falling builds, so it's also useful.


As you can see, currently all Erlang but one packages in nixpkgs are 
taken from hex.pm  as this seem to be the most mature 
centralized package repo for Erlang. It also provides APIs which are 
handy to use in hex2nix conversion tool.


Cheers,
Gleb

On Feb 15, 2016 6:58 AM, "Roger Qiu" > wrote:


Hey Gleb,

Was curious about this, why put erlang packages into the main
nixpkgs repo, and in a separate channel?

The advantages could be that you don't have to wait on nixpkgs to
accept changes to erlang packages.

On the otherhand, maybe it's to take advantage of the CI and hydra
and a concentrated community?

Thanks,
Roger

On 15/02/2016 3:37 AM, Gleb Peregud wrote:


Ah, missed this email before. Just wanted to point out that large
chunk of this support was implemented by Eric B. Merritt, so at
least half of kudos goes to him.

Cheers
Gleb

On Feb 13, 2016 18:20, "stewart mackenzie" > wrote:

Tristan, Gleb Peregud has implemented first class support for
Erlang
in Nix, pleas read the docs:

http://hydra.nixos.org/build/31821726/download/1/nixpkgs/manual.html#users-guide-to-the-erlang-infrastructure

/sjm
___
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


-- 
Founder of Matrix AI

https://matrix.ai/
+61420925975 



--
Founder of Matrix AI
https://matrix.ai/
+61420925975

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

Re: [Nix-dev] [erlang-questions] Erlang Package Manager

[Gleb Peregud]

Ah, missed this email before. Just wanted to point out that large chunk of
this support was implemented by Eric B. Merritt, so at least half of kudos
goes to him.

Cheers
Gleb
On Feb 13, 2016 18:20, "stewart mackenzie"  wrote:

> Tristan, Gleb Peregud has implemented first class support for Erlang
> in Nix, pleas read the docs:
>
> http://hydra.nixos.org/build/31821726/download/1/nixpkgs/manual.html#users-guide-to-the-erlang-infrastructure
>
> /sjm
> ___
> 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] [erlang-questions] Erlang Package Manager

[Eric Pailleau]

https://getcomposer.org/doc/03-cli.md

php have Composer, wich use php binary.
replace php with erl, and count me in.
I cannot see how nix can work pn Windows, even I do not use it.
The PM must run on all plateform where erl is running.
best wishes.


« Envoyé depuis mon mobile » Eric

stewart mackenzie setor...@gmail.com a écrit :

On Wed, Dec 31, 2014 at 11:47 PM, Anthony Ramine n.ox...@gmail.com wrote:
 How do you handle multiple versions of a single package?

Okay allow me to give a rather detailed answer describing in how NixOS
works. I'll also describe how I envisage Erlang adopting Nix as its
package manager.

So I like to think of Nix as the Matrix, you, Neo, can reconfigure
your world at a command. Your entire environment is made up of
thousands of symlinks that can shifted about in an instant. Dodge
speeding bullets - no problem.

Now some code.

A convenient way of creating an environment is using nix-shell. These
files sit in your project folder.

(contents of dev-shell)
#! /bin/sh
s=$(type -p nix-shell)
exec $s release.nix -A erlangEnv

(contents of release.nix)
let
  pkgs = import nixpkgs {};
stdenv = pkgs.stdenv;
  in rec {
erlangEnv = stdenv.mkDerivation rec {
  name = erlang-env;
  version = 1.1.1.1;
  src = ./.;
  buildInputs = [ pkgs.erlang_odbc pkgs.git pkgs.openssl
pkgs.libyaml pkgs.expat pkgs.zlib pkgs.libcouchbase pkgs.automake
pkgs.autoconf pkgs.rebar ];
};
  }

Typically the above is used for short quick projects they are project
specific environments.

See the above 'pkgs.erlang_odbc' that currently points to erlang 17
with odbc support. I can change that to 'pkgs.erlangR16' and it'll
point to Erlang R16.03.

These are the Erlang versions supported
https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/interpreters/erlang
They are exposed via the all-packages.nix file
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix#L3994

You cannot have Erlang R16 and Erlang R17 in the same environment you
will get a conflict.

One could commit dev-shell and release.nix into your repo and
thereafter run  './dev-shell' and you'll leave your current
environment and an environment as dictated by the release.nix will be
created for you.

Now if the Erlang community is considering adopting Nix as its package
manager then the below is the way to do it: Nix already supports
python, perl, php, haskell, node, lua and guile:
https://github.com/NixOS/nixpkgs/tree/master/pkgs/top-level please
notice the language specific *.nix files.

For example
When adding a node package one simply adds the package name to this
file 
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/node-packages.json
and run npm2nix on the file like such: 'npm2nix node-packages.json
node-packages-generated.nix'. The program npm2nix will go to the
canonical https://www.npmjs.com/ and download all the node packages,
update each package and create nix expressions accordingly. The
packager then commits the edited *.json file and the generated file
and makes a pull request for everyone's disposal.

So referring to the previous release.nix example, notice there are no
erlang code dependencies (yes yes forget about rebar).  one would add
'erlangPackages.cowboy'. This then gets the cowboy package that is
part of the nixpkgs.

In other words the Nix community and Erlang community need to start
banging their heads together, create an erlang-packages.nix and extend
it accordingly.

So a rebar2nix program (see https://github.com/NixOS/npm2nix and
https://github.com/NixOS/cabal2nix) could simply be pointed at a git
cloned erlang project from github and it'll parse the rebar.config
file pulling down dependencies, compiling them then making them
immutable derivatives in your nix-store. Note these packages are
obviously not available to everyone in the community. Though if you
run the very same rebar2nix program on the canonical
erlang-packages.nix in
https://github.com/NixOS/nixpkgs/tree/master/pkgs/top-level and
generate a new file, then that would become available to everyone.

Both communities are filled with terribly smart people. You'll get
along just fine.

Now, Nix also supports creating long lasting custom environments
similar to nix-shell but essentially you install this environment as a
package in your /nix/store so to speak.

I have this file ~/.nixpkgs/erlang.nix
```
# $ nix-env -iA erlangEnv -f erlang.nix -p
/nix/var/nix/gcroots/profiles/per-user/erlang
# Make a convenience link.
#  $ ln -sf
/nix/var/nix/gcroots/profiles/per-user/erlang/bin/load-env-erlang .
# Activate the environment.
#  $ ./load-env-erlang
# Optionally, rollback to an earlier generation of this profile.
#  $ nix-env --list-generations -p
/nix/var/nix/gcroots/profiles/per-user/erlang

let
  pkgs = import nixpkgs {};
  stdenv = pkgs.stdenv;
   in rec {
   erlangEnv = pkgs.myEnvFun {
 name = erlang;
 buildInputs = with pkgs; [ erlang rebar openssl git binutils

Re: [Nix-dev] [erlang-questions] Erlang Package Manager

[Anthony Ramine]

How do you handle multiple versions of a single package?

Le 31 déc. 2014 à 16:34, stewart mackenzie setor...@gmail.com a écrit :

 Nix has cabal2nix, npm2nix what is needed is a rebar2nix.
 
 Lets not get too dramatic about it all.
 
 Next you could package Erl deps in the same fashion nix packages
 python, perl and other languages ie include the name
 pythonPackages.package_name. It really isnt far flung to imagine an
 erlangPackages.cowboy
 
 /s
 ___
 erlang-questions mailing list
 erlang-questi...@erlang.org
 http://erlang.org/mailman/listinfo/erlang-questions

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

Re: [Nix-dev] [erlang-questions] Erlang Package Manager

[Tristan Sloughter]

I tried to setup Nix for erlang development months or so ago and walked
away frustrated. Your build-erlang.nix is an example of what I found
unsatisfactory.

Besides the simple fact of needing so much shell scripting (and it would
need more if it was to support more than rebar, or even rebar3) there
was also the need to manually (in the script) perform the linking.

I came to Nix to try this because I thought I would be able to create
build environments per project that only require telling it the
Erlang/OTP version I want and the dependencies -- these being nix
expressions with the url/sha to fetch -- and since all those would be
set to install to something like .../erlang/lib/ I would get a ready
environment with all my deps and Erlang in my path.

That wasn't true, so next I was attempting scripts like you have but
generic and setting ERL_LIBS instead of putting in ./deps/ because I
didn't want it to assume what build tool that is in use.

After fiddling some more I decided it wasn't worth it.

So, it started with my lack of understanding of Nix -- my assumption
that I could simply list dependencies in addition to the ones it would
find based on the binary linking trick it does -- but I think in the end
it just isn't a fit for Erlang development.

-- 
  Tristan Sloughter
  t...@crashfast.com

On Tue, Dec 30, 2014, at 11:49 PM, stewart mackenzie wrote:
 Dear all,
 
 I am an Erlang programmer and I use NixOS almost exclusively.
 
 Here is a nix project that compiles and deploys MongooseIM
 
 https://github.com/headcounter/deployment
 
 You can visit www.headcounter.org/hydra to see the CI.
 Particularly this build: https://headcounter.org/hydra/eval/14531
 which also runs the tests :
 https://headcounter.org/hydra/build/447454/download/1/ct_report/
 and builds the manual.
 
 Points of interest:
 This file builds the erlang dependencies:
 https://github.com/headcounter/deployment/blob/master/pkgs/build-support/build-erlang.nix
 Here are the erlang dependencies for MongooseIM :
 https://github.com/headcounter/deployment/tree/master/pkgs/erldeps
 This folder deals with MongooseIM:
 https://github.com/headcounter/deployment/tree/master/pkgs/mongooseim
 
 Have fun!
 
 We'll be rolling out NixOS in production shortly.
 
 Kind regards
 Stewart
 
 
 On Wed, Dec 31, 2014 at 1:00 PM, Anderson Torres
 torres.anderson...@gmail.com wrote:
  I think using Nix is very attractive:
  - we are a small team by now, and we need more programmers and
  beta-testers (as almost any big project).
  - also, we can serve as a platform for popularizing Erlang.
 ___
 erlang-questions mailing list
 erlang-questi...@erlang.org
 http://erlang.org/mailman/listinfo/erlang-questions
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [erlang-questions] Erlang Package Manager

[stewart mackenzie]

Nix has cabal2nix, npm2nix what is needed is a rebar2nix.

Lets not get too dramatic about it all.

Next you could package Erl deps in the same fashion nix packages
python, perl and other languages ie include the name
pythonPackages.package_name. It really isnt far flung to imagine an
erlangPackages.cowboy

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

Re: [Nix-dev] [erlang-questions] Erlang Package Manager

[stewart mackenzie]

On Wed, Dec 31, 2014 at 11:47 PM, Anthony Ramine n.ox...@gmail.com wrote:
 How do you handle multiple versions of a single package?

Okay allow me to give a rather detailed answer describing in how NixOS
works. I'll also describe how I envisage Erlang adopting Nix as its
package manager.

So I like to think of Nix as the Matrix, you, Neo, can reconfigure
your world at a command. Your entire environment is made up of
thousands of symlinks that can shifted about in an instant. Dodge
speeding bullets - no problem.

Now some code.

A convenient way of creating an environment is using nix-shell. These
files sit in your project folder.

(contents of dev-shell)
#! /bin/sh
s=$(type -p nix-shell)
exec $s release.nix -A erlangEnv

(contents of release.nix)
let
  pkgs = import nixpkgs {};
stdenv = pkgs.stdenv;
  in rec {
erlangEnv = stdenv.mkDerivation rec {
  name = erlang-env;
  version = 1.1.1.1;
  src = ./.;
  buildInputs = [ pkgs.erlang_odbc pkgs.git pkgs.openssl
pkgs.libyaml pkgs.expat pkgs.zlib pkgs.libcouchbase pkgs.automake
pkgs.autoconf pkgs.rebar ];
};
  }

Typically the above is used for short quick projects they are project
specific environments.

See the above 'pkgs.erlang_odbc' that currently points to erlang 17
with odbc support. I can change that to 'pkgs.erlangR16' and it'll
point to Erlang R16.03.

These are the Erlang versions supported
https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/interpreters/erlang
They are exposed via the all-packages.nix file
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix#L3994

You cannot have Erlang R16 and Erlang R17 in the same environment you
will get a conflict.

One could commit dev-shell and release.nix into your repo and
thereafter run  './dev-shell' and you'll leave your current
environment and an environment as dictated by the release.nix will be
created for you.

Now if the Erlang community is considering adopting Nix as its package
manager then the below is the way to do it: Nix already supports
python, perl, php, haskell, node, lua and guile:
https://github.com/NixOS/nixpkgs/tree/master/pkgs/top-level please
notice the language specific *.nix files.

For example
When adding a node package one simply adds the package name to this
file 
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/node-packages.json
and run npm2nix on the file like such: 'npm2nix node-packages.json
node-packages-generated.nix'. The program npm2nix will go to the
canonical https://www.npmjs.com/ and download all the node packages,
update each package and create nix expressions accordingly. The
packager then commits the edited *.json file and the generated file
and makes a pull request for everyone's disposal.

So referring to the previous release.nix example, notice there are no
erlang code dependencies (yes yes forget about rebar).  one would add
'erlangPackages.cowboy'. This then gets the cowboy package that is
part of the nixpkgs.

In other words the Nix community and Erlang community need to start
banging their heads together, create an erlang-packages.nix and extend
it accordingly.

So a rebar2nix program (see https://github.com/NixOS/npm2nix and
https://github.com/NixOS/cabal2nix) could simply be pointed at a git
cloned erlang project from github and it'll parse the rebar.config
file pulling down dependencies, compiling them then making them
immutable derivatives in your nix-store. Note these packages are
obviously not available to everyone in the community. Though if you
run the very same rebar2nix program on the canonical
erlang-packages.nix in
https://github.com/NixOS/nixpkgs/tree/master/pkgs/top-level and
generate a new file, then that would become available to everyone.

Both communities are filled with terribly smart people. You'll get
along just fine.

Now, Nix also supports creating long lasting custom environments
similar to nix-shell but essentially you install this environment as a
package in your /nix/store so to speak.

I have this file ~/.nixpkgs/erlang.nix
```
# $ nix-env -iA erlangEnv -f erlang.nix -p
/nix/var/nix/gcroots/profiles/per-user/erlang
# Make a convenience link.
#  $ ln -sf
/nix/var/nix/gcroots/profiles/per-user/erlang/bin/load-env-erlang .
# Activate the environment.
#  $ ./load-env-erlang
# Optionally, rollback to an earlier generation of this profile.
#  $ nix-env --list-generations -p
/nix/var/nix/gcroots/profiles/per-user/erlang

let
  pkgs = import nixpkgs {};
  stdenv = pkgs.stdenv;
   in rec {
   erlangEnv = pkgs.myEnvFun {
 name = erlang;
 buildInputs = with pkgs; [ erlang rebar openssl git binutils
bash emacs which libyaml expat zlib automake autoconf mc libtool
python libevent meld tig libpcap cmake libcouchbase pidgin ];
   };
   }
```

So this allows one to have generations such that one can rollback if
something messed up. These environments can be quite complex if
needed. You are limited by your creativity and the