Re: [Nix-dev] Project environment setup

[Alex Berg]

Also, you probably already found it, but there is some docs in the nixpkgs
manual, called "11.2.5. How to create ad hoc environments for nix-shell"

On Mon, Jul 18, 2016 at 9:41 PM, Alex Berg <chex...@gmail.com> wrote:

> Looks like that shell.nix file is correct.
>
> That load-time is only the first time, right? On the first run, all
> dependencies are fetched, but after that there is no need.
>
> What are you expecting? If you enter that nix-shell, you'll have a
> `gradle` command. Are you expecting a `java` command, also? If you want a
> `java` command, then you need to add a jdk to the "buildInputs". You can
> add `pkgs.openjdk7`, and the `java` command will run that while the
> `gradle` command refers to openjdk8. If you want `java` command to use
> openjdk8, then add `pkgs.openjdk8` to the "buildInputs".
>
>
> On Mon, Jul 18, 2016 at 8:17 PM, Ryan Eckbo <ec...@cim.mcgill.ca> wrote:
>
>> For example, the shell.nix I wrote below doesn't make a gradle
>> available with openjdk8, and also takes 2m20s to load (!) when
>> I run `nix-shell`:
>>
>> # shell.nix
>> # nix-shell prints 'warning: dumping very large path (> 256 MiB); this
>> may run out of memory'
>> { pkgs ? import  {} }:
>>
>> let
>>   mygradle = pkgs.lib.overrideDerivation pkgs.gradle25 (oldAttrs: {
>> jdk = pkgs.openjdk8;
>> });
>> in
>> pkgs.stdenv.mkDerivation {
>> name = "myproject";
>> src = ./.;
>> buildInputs = [ mygradle ];
>>
>> }
>>
>>
>>
>> On 19 Jul 2016, at 10:53, Ryan Eckbo wrote:
>>
>> I've been reading the docs and blog posts but I'm still unsure on the
>>> proper
>>> way to configure a local shell.nix with my required modified packages.
>>> Specifically, I need gradle built with jdk 8, something like
>>>
>>>pkgs.gradle25.override { jdk = pkgs.openjdk8; }
>>>
>>> and I also have some local nix expressions. But I only want this for one
>>> project (so no
>>> setting of .nixpkgs/config.nix).  Can someone point me in the right
>>> direction?
>>>
>>> Thanks!
>>> Ryan
>>>
>>> ___
>>> 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

Re: [Nix-dev] Project environment setup

[Alex Berg]

Looks like that shell.nix file is correct.

That load-time is only the first time, right? On the first run, all
dependencies are fetched, but after that there is no need.

What are you expecting? If you enter that nix-shell, you'll have a `gradle`
command. Are you expecting a `java` command, also? If you want a `java`
command, then you need to add a jdk to the "buildInputs". You can add
`pkgs.openjdk7`, and the `java` command will run that while the `gradle`
command refers to openjdk8. If you want `java` command to use openjdk8,
then add `pkgs.openjdk8` to the "buildInputs".


On Mon, Jul 18, 2016 at 8:17 PM, Ryan Eckbo  wrote:

> For example, the shell.nix I wrote below doesn't make a gradle
> available with openjdk8, and also takes 2m20s to load (!) when
> I run `nix-shell`:
>
> # shell.nix
> # nix-shell prints 'warning: dumping very large path (> 256 MiB); this may
> run out of memory'
> { pkgs ? import  {} }:
>
> let
>   mygradle = pkgs.lib.overrideDerivation pkgs.gradle25 (oldAttrs: {
> jdk = pkgs.openjdk8;
> });
> in
> pkgs.stdenv.mkDerivation {
> name = "myproject";
> src = ./.;
> buildInputs = [ mygradle ];
>
> }
>
>
>
> On 19 Jul 2016, at 10:53, Ryan Eckbo wrote:
>
> I've been reading the docs and blog posts but I'm still unsure on the
>> proper
>> way to configure a local shell.nix with my required modified packages.
>> Specifically, I need gradle built with jdk 8, something like
>>
>>pkgs.gradle25.override { jdk = pkgs.openjdk8; }
>>
>> and I also have some local nix expressions. But I only want this for one
>> project (so no
>> setting of .nixpkgs/config.nix).  Can someone point me in the right
>> direction?
>>
>> Thanks!
>> Ryan
>>
>> ___
>> 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

Re: [Nix-dev] Improve docs for overrideDerivation - overridable attributes

[Alex Berg]

I updated the "overrideDerivation" docs yesterday to clarify this. Was
merged today.
https://github.com/NixOS/nixpkgs/pull/16867

Thanks, all!


On Fri, Jul 1, 2016 at 10:00 AM, Profpatsch <m...@profpatsch.de> wrote:

> On 16-06-30 11:18am, Alex Berg wrote:
> > Where can I find explanation for this? If there is a restriction on which
> > attributes are overridable, then I'd like to note this in the NixPkgs
> > manual, here:
> > https://nixos.org/nixpkgs/manual/index.html#sec-pkg-overrideDerivation
>
> I have a short overview of the various kinds of overriding mechanisms here:
> https://github.com/Profpatsch/nixpkgs-cheatsheet/blob/master/cheatsheet.org
>
> --
> 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.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] b5a95b: Improve overrideDerivation docs. (#16867)

[Alex Berg]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b5a95b181297da1f2bb720cc0f3338d16a8c4355
  
https://github.com/NixOS/nixpkgs/commit/b5a95b181297da1f2bb720cc0f3338d16a8c4355
  Author: Alex Berg <chex...@users.noreply.github.com>
  Date:   2016-07-12 (Tue, 12 Jul 2016)

  Changed paths:
M doc/functions.xml

  Log Message:
  ---
  Improve overrideDerivation docs. (#16867)

* Improve overrideDerivation docs.

Explain how antiquotation in a package's attribute behaves when overriding the 
package.

* Edit antiquotation note. Fix closing-element.


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

Re: [Nix-dev] Improve docs for overrideDerivation - overridable attributes

[Alex Berg]

Oh wow! I never would have guessed this was a behavior of the `rec`
keyword! Nice idea!
I'll play around with it to verify my understanding and then submit a PR to
the NixPkgs manual to note this behavior for other people who might
discover this pitfall. That'll take me several days. :)

Much appreciated, Layus!

On Thu, Jun 30, 2016 at 12:01 PM, Layus <layus...@gmail.com> wrote:

> On 30/06/16 20:18, Alex Berg wrote:
>
> I created a new "~/.nixpkgs/config.nix" file to customize the
> nix-channel-obtained nixpkgs copy on my system - my goal was to bump the
> version of Vim to a specific version.
>
> My first attempt was to override the derivation and simply set the
> "version" attribute, like this:
>
> {
>   packageOverrides = pkgs: rec {
> vim = pkgs.vim.overrideDerivation (oldAttrs: {
>   version = "7.4.1941";
> });
>   };
> }
>
> But this had zero effect on the name of Vim I saw when using "nix-env
> -qaP" to see package details. The Vim package's definition has the "name"
> attribute defined like this:
>
> name = "vim-${version}";
> version = "7.4.1585";
>
> so I expected my overriding the "version" attribute to affect the
> package's name, but it did not.
>
> No, because the definition above relies on the "rec" keyword, but "rec"
> has already been applied *before* overrideDerivation.
> Overriding "version" will not override "name", and in turn will not
> override "src".
> In fact, overriding "version" will have no impact on the output path as
> that parameter is not used by mkDerivation.
> But the attribute is overriden. ` nix-instantiate "" --eval -A
> vim.version ` will give you the new version string.
>
> Overriding "name", for example, will have impact as it is used by
> mkDerivation to compute the output path.
> Again, it is not sufficient to build a different version of vim. See below.
>
>
> After asking the #nixos IRC channel, one person suggested the "version"
> attribute isn't overridable because it isn't an attribute the *primitive
> derivation* set. Based on this guess, I changed my ~/.nixpkgs/config.nix
> definition from that to this:
>
> let
>   vim-version = "7.4.1941";
> in
> {
>   packageOverrides = pkgs: rec {
> vim = pkgs.vim.overrideDerivation (oldAttrs: {
>   name = "vim-${vim-version}";
>   src = pkgs.fetchFromGitHub {
> owner = "vim";
> repo = "vim";
> rev = "v${vim-version}";
> sha256 = "0apq7sv1fbyfzqh4q0r2z19bn4gbjlb97wyl80kj7qsqmsy7m1lm";
>   };
> });
>   };
> }
>
> My guess is this works because I'm overriding the "name" attribute.
>
> No, it works because you override the "src" attribute.
> src is used by mkDerivation, so overriding modifies the package to be
> built with the new source tree.
> Overriding the name is not strictly necessary, but is a *very* good
> practice, as otherwise you would get a 7.4.1941 vim with the old version in
> the name... confusing :-)
>
>
> I read the definition of the "mkDerivation" function 
> (pkgs/stdenv/generic/default.nix),
> but it doesn't have a simple list of attributes that are overridable, but
> is rather flexible. Also, that definition doesn't mention a "src"
> attribute, but "src" attribute is overridable, so I wonder why overriding
> the "src" attribute works.
>
> Where can I find explanation for this? If there is a restriction on which
> attributes are overridable, then I'd like to note this in the NixPkgs
> manual, here:
> <https://nixos.org/nixpkgs/manual/index.html#sec-pkg-overrideDerivation>
> https://nixos.org/nixpkgs/manual/index.html#sec-pkg-overrideDerivation
>
> Everything is overridable separately, but you cannot count on the rec
> keyword at override time.
> Every attribute already has a fully defined value.
>
>
>
>
> ___
> nix-dev mailing 
> listnix-...@lists.science.uu.nlhttp://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

[Nix-dev] Improve docs for overrideDerivation - overridable attributes

[Alex Berg]

I created a new "~/.nixpkgs/config.nix" file to customize the
nix-channel-obtained nixpkgs copy on my system - my goal was to bump the
version of Vim to a specific version.

My first attempt was to override the derivation and simply set the
"version" attribute, like this:

{
  packageOverrides = pkgs: rec {
vim = pkgs.vim.overrideDerivation (oldAttrs: {
  version = "7.4.1941";
});
  };
}

But this had zero effect on the name of Vim I saw when using "nix-env -qaP"
to see package details. The Vim package's definition has the "name"
attribute defined like this:

name = "vim-${version}";
version = "7.4.1585";

so I expected my overriding the "version" attribute to affect the package's
name, but it did not.

After asking the #nixos IRC channel, one person suggested the "version"
attribute isn't overridable because it isn't an attribute the *primitive
derivation* set. Based on this guess, I changed my ~/.nixpkgs/config.nix
definition from that to this:

let
  vim-version = "7.4.1941";
in
{
  packageOverrides = pkgs: rec {
vim = pkgs.vim.overrideDerivation (oldAttrs: {
  name = "vim-${vim-version}";
  src = pkgs.fetchFromGitHub {
owner = "vim";
repo = "vim";
rev = "v${vim-version}";
sha256 = "0apq7sv1fbyfzqh4q0r2z19bn4gbjlb97wyl80kj7qsqmsy7m1lm";
  };
});
  };
}

My guess is this works because I'm overriding the "name" attribute.

I read the definition of the "mkDerivation" function
(pkgs/stdenv/generic/default.nix),
but it doesn't have a simple list of attributes that are overridable, but
is rather flexible. Also, that definition doesn't mention a "src"
attribute, but "src" attribute is overridable, so I wonder why overriding
the "src" attribute works.

Where can I find explanation for this? If there is a restriction on which
attributes are overridable, then I'd like to note this in the NixPkgs
manual, here:
https://nixos.org/nixpkgs/manual/index.html#sec-pkg-overrideDerivation
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] How to version-bump haskell package in nix-shell?

[Alex Berg]

I have a shell.nix file to give me a shell which has PureScript in it. I
sometimes want to version-bump that. How do I do that? I pasted my
shell.nix file at the bottom of this message, which includes a few attempts
at doing this.

I see that boothead is doing what I want in his shell.nix [1], but not in
the way I want to do it. He is redefining the *entire* package in a local
file, but I want to just edit the version and sha256 attributes of the
central nix expression.

The Modifying Packages wiki page [2] says we can use an override
attribute to add custom values to attributes, which sounds like exactly
what I want to do. However, all the examples I see, including the Haskell
wiki page [3], teach us to redefine the entire package in a local file.
Surely we are also able to use the override attribute here, can't we? The
override technique seems so much simpler and needs less boilerplate.

I did some source-code reading, which isn't fun, and I found a function
called makeOverridable [4]. If we add that function to the cabal builder
here [5], will this allow us to use this override technique?

If I add stdenv.lib.makeOverridable here, will I be able to do
haskellPackages.somePackage.override { version = 1.2.4 } ?

[1] https://github.com/boothead/purescript-nix/blob/master/shell.nix
[2]
https://nixos.org/wiki/Nix_Modifying_Packages#Overriding_Existing_Packages
[3]
https://nixos.org/wiki/Haskell#Maintaining_your_own_set_of_additional_Haskell_packages
[4]
https://github.com/NixOS/nixpkgs/blob/492dd14e78aebea0722dcb6becb2d6601ad51dc8/lib/customisation.nix
[5]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cabal/default.nix#L312


- shell.nix -

{ }:

with import nixpkgs {};

#let purescript = pkgs.stdenv.lib.overrideDerivation
pkgs.haskellPackages.purescript ( oldAttrs : {
#   src = {
#   version = 0.6.2;
#   sha256 = ;
#   };
#});
let purescript = pkgs.haskellPackages.purescript.override {
version = 0.6.2;
sha256 = ;
};
#let haskellPackages = pkgs.haskellPackages.override {
#   extension = self: super: {
#   #purescript = self.callPackage ./purescript.nix {
#   purescript = self.purescript.override {
#   version = 0.6.2;
#   sha256 = ;
#};
#   };
#};
in rec {
pursEnv = stdenv.mkDerivation rec {
name = purescript-env;
version = 1.1.1.1;
src = ./.;
buildInputs = [
#haskellPackages.purescript
purescript
pkgs.nodePackages.grunt-cli
pkgs.nodePackages.bower
git
which
vim
tree
];
shellHook =
  ''
echo Patching NODE_PATH
export
NODE_PATH=$NODE_PATH:/nix/store/hhpwgi9k2j3c0r4q6rn0l0cf1r8vf98q-node-es5-ext-0.10.4/lib/node_modules
  '';
};
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NPM package - Bower dependency can't find dependency

[Alex Berg]

I can't figure out this NPM stuff, and I don't want to keep spinning my
tires on this when the new npm2nix thing might fix this. I can't even
figure out how that tool is supposed to be used. I wish there was a
conceptual documentation page on the wiki or something.

As a workaround, I changed my shell.nix to manually inject the path I need
into the NODE_PATH env variable. I found the missing dependency by running
this command and just picking one.

find /nix/store -type d -name es5-ext

Here is my new shell.nix


-- shell.nix 

{ }:

with import nixpkgs {};

let haskellPackages = pkgs.haskellPackages.override {
extension = self: super: {
# purescript = self.callPackage ./purescript.nix {};
};
};
nodePkgs = pkgs.nodePackages;
in rec {
pursEnv = stdenv.mkDerivation rec {
name = purescript-env;
version = 1.1.1.1;
src = ./.;
buildInputs = [
haskellPackages.purescript
nodePkgs.bower
nodePkgs.grunt-cli
git
which
];
shellHook =
  ''
echo Patching NODE_PATH
export
NODE_PATH=$NODE_PATH:/nix/store/hhpwgi9k2j3c0r4q6rn0l0cf1r8vf98q-node-es5-ext-0.10.4/lib/node_modules
  '';

};
}

On Sat, Nov 22, 2014 at 10:32 AM, Alex Berg chex...@gmail.com wrote:


 I'm working on this today to narrow down where the issue lies, so I want
 to poll  other's progress on this. I believe it's related to propagated
 build-inputs.

 I am trying to use purescript, grunt, and bower. All are working fine, but
 bower is not. The error message is pasted below.

 What's the status of recursive dependency resolution for NPM packages? I
 remember seeing lots of work on it in the last 1-2 months.

 Looks like the d library can't find the es5-ext/object/assign library.
 I believe the latter is a part of the standard library, which I believe
 should be part of the base node package.


 -- shell.nix 

 { }:

 with import nixpkgs {};

 let haskellPackages = pkgs.haskellPackages.override {
 extension = self: super: {
 # purescript = self.callPackage ./purescript.nix {};
 };
 };
 nodePkgs = pkgs.nodePackages;
 in rec {
 pursEnv = stdenv.mkDerivation rec {
 name = purescript-env;
 version = 1.1.1.1;
 src = ./.;
 buildInputs = [
 haskellPackages.purescript
 nodePkgs.bower
 nodePkgs.grunt-cli
 git
 ];
 };
 }


 - NODE_PATH ---

 [nix-shell:~/dev/purescript-test]$ echo $NODE_PATH

 /nix/store/95k5x06vfspkfi2sw43nsjydffqsdahz-bin-bower-1.3.12/lib/node_modules:/nix/store/l56ffyyz233bi8njxp3cyn9qgpd1pwqj-nodejs-0.10.32/lib/node_modules:/nix/store/smrcylf038p9z8r3fs8rwarv9dg
 iahcy-bin-grunt-cli-0.1.13/lib/node_modules


 - Error paste --

 [nix-shell:~/dev/purescript-test]$ bower

 module.js:340
 throw err;
   ^
 Error: Cannot find module 'es5-ext/object/assign'
 at Function.Module._resolveFilename (module.js:338:15)
 at Function.Module._load (module.js:280:25)
 at Module.require (module.js:364:17)
 at require (module.js:380:17)
 at Object.anonymous
 (/nix/store/izf6avvrfmix793z3mwhwdb77bx3j8z7-node-d-0.1.1/lib/node_modules/d/index.js:3:21)
 at Module._compile (module.js:456:26)
 at Object.Module._extensions..js (module.js:474:10)
 at Module.load (module.js:356:32)
 at Function.Module._load (module.js:312:12)
 at Module.require (module.js:364:17)


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

[Nix-dev] NPM package - Bower dependency can't find dependency

[Alex Berg]

I'm working on this today to narrow down where the issue lies, so I want to
poll  other's progress on this. I believe it's related to propagated
build-inputs.

I am trying to use purescript, grunt, and bower. All are working fine, but
bower is not. The error message is pasted below.

What's the status of recursive dependency resolution for NPM packages? I
remember seeing lots of work on it in the last 1-2 months.

Looks like the d library can't find the es5-ext/object/assign library.
I believe the latter is a part of the standard library, which I believe
should be part of the base node package.


-- shell.nix 

{ }:

with import nixpkgs {};

let haskellPackages = pkgs.haskellPackages.override {
extension = self: super: {
# purescript = self.callPackage ./purescript.nix {};
};
};
nodePkgs = pkgs.nodePackages;
in rec {
pursEnv = stdenv.mkDerivation rec {
name = purescript-env;
version = 1.1.1.1;
src = ./.;
buildInputs = [
haskellPackages.purescript
nodePkgs.bower
nodePkgs.grunt-cli
git
];
};
}


- NODE_PATH ---

[nix-shell:~/dev/purescript-test]$ echo $NODE_PATH
/nix/store/95k5x06vfspkfi2sw43nsjydffqsdahz-bin-bower-1.3.12/lib/node_modules:/nix/store/l56ffyyz233bi8njxp3cyn9qgpd1pwqj-nodejs-0.10.32/lib/node_modules:/nix/store/smrcylf038p9z8r3fs8rwarv9dg
iahcy-bin-grunt-cli-0.1.13/lib/node_modules


- Error paste --

[nix-shell:~/dev/purescript-test]$ bower

module.js:340
throw err;
  ^
Error: Cannot find module 'es5-ext/object/assign'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.anonymous
(/nix/store/izf6avvrfmix793z3mwhwdb77bx3j8z7-node-d-0.1.1/lib/node_modules/d/index.js:3:21)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] This Week in NixOS

[Alex Berg]

I think this is really valuable thing. Please do contact someone if you
need help with that. A buddy makes the load lighter.
On May 25, 2014 1:23 PM, Georges Dubus georges.du...@gmail.com wrote:

 Hello there

 I mentioned the idea on irc some time ago, and I finally gathered the
 courage to do it : here is the first issue of This Week in NixOS[1].

 For this first issue, I browsed the various git logs and tried to pick up
 the most remarkable commits, but I'm sure I have missed many. If you do or
 see something that should appear in the next issues, please send me an
 email to make sure it is included.

 Also, this first issue is quite short. What additional sections would you
 like to see in the next issues? I'm thinking about a list of new
 contributors and an exhaustive list of package updates.


 Finally, I believe my NixOS atom feed[2] might be worth adding to the
 planet, so this is also an open letter to any planet admin!

 [1] http://compiletoi.net/this-week-in-nixos-1.html
 [2] http://compiletoi.net/feeds/nixos.atom.xml
 --
 Georges Dubus

 ___
 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] Restructuring of the Wiki

[Alex Berg]

Thanks for the link to past discussion on this topic, Cillian. That was a
good discussion. Also, thank you, Third3ye, for contributing to the wiki
effort and raising Nix wiki awareness.

### On the Nix Wiki

A wiki is a low-barrier way to build a database of eventually consistent
and correct info. Good topics for this info includes history, design, and
purpose of entities, in addition to explaining relationships between topics.

In Nix project's case, several areas need such info - OS-management,
software building/distribution, and development environments using Nix. Our
wiki is not only for NixOS info, nor is it only for developers to document
their additions to Nix code. It's a place for seeing the big picture, of
both Nix and as it is meant to relate to other things. This includes its
relationship with ubiquitous software design problems or just to help out
our current projects.

If you want to add a page which doesn't fit in this picture, should you
forget about adding it? No. Just add it somewhere. Wiki maintainers, who
care about enforcing the wiki's design, can assimilate it by moving it to
the right place and editing it's style.

Now, having said that, do we still need to change how the wiki works? I'm
pretty happy with our wiki. We have zero spam now. We just need to complete
it's redesign, and new users should feel more confident adding content to
the skeleton. We've been playing with a new main page [1], but it's not
finished.

The OP also mentioned machine-generated pages. I'm not a fan. This implies
two different places to visit to edit the wiki, which distracts from the
wiki's purpose of a *central* place for community-maintained big-picture
info.

### On Moving the Wiki

This thread *does* include some discussion on moving the wiki, and I didn't
comment in last year's thread on that topic, so I'll do so now.

Requirements for software which enables this kind of information
compilation:

1) Easy for non-coders to contribute
2) Searchable
3) History of content, to recover lost info

Nice to have:

3) Organizable into topics
4) Software is easy to maintain
5) Content is portable

If we want to become A GitHub Project, we can
- Use their wiki system
- Create a new Git repo called wiki. We can edit and commit file changes
in GitHub browser UI.

I'm not a fan of becoming A GitHub Project, because the Nix project is
bigger than just GitHub. How so? We have several other web sites which are
essential to Nix, including Hydra, online manuals, and the Nix homepage
itself. Also, fads come and go, and GitHub may be just a fad.

I *am* a fan, however, of having a file-based backend which still keeps
file history. I would *only* consider such a system if they can be
maintained entirely through a browser. It looks like these are both
features of Gitit.

[1] https://nixos.org/wiki/Main_Page_B



On Mon, May 19, 2014 at 9:29 AM, Anderson Torres 
torres.anderson...@gmail.com wrote:

 About documentation itself, I find the format of famous FreeBSD Handbook
 (http://www.freebsd.org/doc/handbook/) very appealing. It can be used as
 a guide to our wiki or even a book on its own.

 Also, a thing I miss in the wiki is a 'hacking guide' inside Nixpkgs and
 Nix programming in general. I would like if some functions as callPackage,
 recurseIntoAttrs were more explained with examples or whatever.







 2014-05-19 8:22 GMT-03:00 Cillian de Róiste cillian.deroi...@gmail.com:

 For reference, here's the discussion from the last time the topic of
 changing wiki platform came up, last year:
 http://lists.science.uu.nl/pipermail/nix-dev/2013-March/010800.html
 ___
 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

Re: [Nix-dev] Restructuring of the Wiki

[Alex Berg]

I've not heard that we have a specially designated team of wiki
maintainers.

If we want to use user permissions as an indicator of responsibility, we
have 3 wiki admins: Chexxor, Goibhniu, and EelcoDolstra:


On Mon, May 19, 2014 at 12:45 PM, Kirill Elagin kirela...@gmail.com wrote:

 On Mon, May 19, 2014 at 7:13 PM, Alex Berg chex...@gmail.com wrote:

 Thanks for the link to past discussion on this topic, Cillian. That was a
 good discussion. Also, thank you, Third3ye, for contributing to the wiki
 effort and raising Nix wiki awareness.

 ### On the Nix Wiki

 A wiki is a low-barrier way to build a database of eventually consistent
 and correct info. Good topics for this info includes history, design, and
 purpose of entities, in addition to explaining relationships between topics.

 In Nix project's case, several areas need such info - OS-management,
 software building/distribution, and development environments using Nix. Our
 wiki is not only for NixOS info, nor is it only for developers to document
 their additions to Nix code. It's a place for seeing the big picture, of
 both Nix and as it is meant to relate to other things. This includes its
 relationship with ubiquitous software design problems or just to help out
 our current projects.

 If you want to add a page which doesn't fit in this picture, should you
 forget about adding it? No. Just add it somewhere. Wiki maintainers, who
 care about enforcing the wiki's design, can assimilate it by moving it to
 the right place and editing it's style.


 Do we have a specially designated team of wiki maintainers?


  Now, having said that, do we still need to change how the wiki works?
 I'm pretty happy with our wiki. We have zero spam now. We just need to
 complete it's redesign, and new users should feel more confident adding
 content to the skeleton. We've been playing with a new main page [1], but
 it's not finished.

 The OP also mentioned machine-generated pages. I'm not a fan. This
 implies two different places to visit to edit the wiki, which distracts
 from the wiki's purpose of a *central* place for community-maintained
 big-picture info.

 ### On Moving the Wiki

 This thread *does* include some discussion on moving the wiki, and I
 didn't comment in last year's thread on that topic, so I'll do so now.

 Requirements for software which enables this kind of information
 compilation:

 1) Easy for non-coders to contribute
 2) Searchable
 3) History of content, to recover lost info

 Nice to have:

 3) Organizable into topics
 4) Software is easy to maintain
 5) Content is portable


 It looks like any reasonable wiki software can offer all of this. Gollum
 and Gitit included.


 If we want to become A GitHub Project, we can
 - Use their wiki system
 - Create a new Git repo called wiki. We can edit and commit file
 changes in GitHub browser UI.

 I'm not a fan of becoming A GitHub Project, because the Nix project is
 bigger than just GitHub. How so? We have several other web sites which are
 essential to Nix, including Hydra, online manuals, and the Nix homepage
 itself. Also, fads come and go, and GitHub may be just a fad.


 Again, staying inside GitHub for their wiki is not necessary. We can run
 their wiki (Gollum) standalone on nixos.org domain and be happy with it.
 So, basically, if we are talking about migration we just have to choose
 one of the engines which all seem to be nice. Again, I feel that opening an
 issue for this would be handy.

 But wiki organisation is way more important than the engine used. And I'd
 like to hear more on this topic. It would be nice to have guides on writing
 wiki articles and wiki organisation.
 Are those available anywhere in written form?


 I *am* a fan, however, of having a file-based backend which still keeps
 file history. I would *only* consider such a system if they can be
 maintained entirely through a browser. It looks like these are both
 features of Gitit.

 [1] https://nixos.org/wiki/Main_Page_B



 On Mon, May 19, 2014 at 9:29 AM, Anderson Torres 
 torres.anderson...@gmail.com wrote:

 About documentation itself, I find the format of famous FreeBSD
 Handbook (http://www.freebsd.org/doc/handbook/) very appealing. It can
 be used as a guide to our wiki or even a book on its own.

 Also, a thing I miss in the wiki is a 'hacking guide' inside Nixpkgs and
 Nix programming in general. I would like if some functions as callPackage,
 recurseIntoAttrs were more explained with examples or whatever.







 2014-05-19 8:22 GMT-03:00 Cillian de Róiste cillian.deroi...@gmail.com
 :

 For reference, here's the discussion from the last time the topic of
 changing wiki platform came up, last year:
 http://lists.science.uu.nl/pipermail/nix-dev/2013-March/010800.html
 ___
 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

Re: [Nix-dev] stripHash

[Alex Berg]

I thought the documentation for the standard environment in the Nix manual
needed, some updating, so I wrote a wiki page a few months ago. There's a
section there which describes all of those library functions [1]. I didn't
see anything which suggests it is printed to stdout. Here's the current
implementation [2].

It's possible the manual became incorrect. Does anyone else know how
stripHash should behave?

[1] https://nixos.org/wiki/NixPkgs_Standard_Environment#Library_Functions
[2]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L418
 On Apr 7, 2014 8:39 PM, Colin Putney co...@wiresong.com wrote:

 Hi all,

 The Nixpkgs Manual mentions that stdenv provides a shell function,
 stripHash, that will strip off the directory and hash part of a store path,
 and print out just the name. (See
 http://nixos.org/nixpkgs/manual/#fun-stripHash).

 However, it doesn't actually print anything out. (At least not in my
 environment--nixpkgs from the unstable channel, recently updated). Digging
 further:

 [nix-shell:/tmp/build]$ type stripHash
 stripHash is a function
 stripHash ()
 {
 strippedName=$(basename $1);
 if echo $strippedName | grep -q '^[a-z0-9]\{32\}-'; then
 strippedName=$(echo $strippedName | cut -c34-);
 fi
 }

 It seems that it's correctly stripping off the name, but not echoing it as
 the manual suggests. And sure enough, poking around in builder scripts in
 nixpkgs, there are lots of uses of stripHash that follow this pattern:

 $(stripHash $foo; echo $strippedName)

 Is this a bug that everybody just works around, or is it the desired
 behaviour?

 Colin

 ___
 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] Help creating a custom app with Nix package manager

[Alex Berg]

Yo Asus, you're a bit slow receiving a response from the list for this
issue. Apologies!

That error message - cannot auto-call a function... - this occurs when
when you call a Nix function but don't supply a requested value.

Here's [1] a page on the NixOS wiki where I'm trying to gather common error
messages. This one is on that list.
That page links to this [2] older email thread from someone with a similar
issue.

In Nix, functions can take named arguments. Here's a page [3] which
describes this concept implemented in C#.

In your case, your package's function signature includes a whole set of
arguments

 { stdenv, fetchurl, pkgconfig, libsoup, webkit, gtk,
glib_networking, gsettings_desktop_schemas, makeWrapper  }:

Here's where to wiggle the code to fix it. If you want to call this
function, a value must be specified for each parameter.

luakit = callPackage ../applications/networking/browsers/luakit {
 inherit stdenv; # Add some more arguments here. Check other
packages for examples.
 inherit (gnome) libsoup;
 webkit = webkit_gtk2;
 };

Now, IIRC, the `callPackage` function should resolve most of these
arguments automatically, so we shouldn't need to give `stdenv` a value. So,
this is why I can't give you an exact solution. Take a bit to read the
source code a bit, here [4], and read backwards to see how that is
implemented. Hopefully there's some comments.

Apologies for my laziness to completely solve the problem for you!


[1] https://nixos.org/wiki/Error_Messages
[2] http://lists.science.uu.nl/pipermail/nix-dev/2009-July/002671.html
[3] http://msdn.microsoft.com/en-us/library/dd264739.aspx
[4]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix#L146


On Thu, Feb 27, 2014 at 8:30 AM, Asus Ceaser theprepb...@gmail.com wrote:

 I did a fresh install and started following the Nixpkgs manual to
 create a custom package.  I want to use the web browser luakit.

 So I cloned the git repository and changed directory into it.

 I then created the directory luakit under
 /pkgs/applications/network/browsers/

 I created a default.nix which looks like this:

  { stdenv, fetchurl, pkgconfig, libsoup, webkit, gtk, glib_networking,
 gsettings_desktop_schemas, makeWrapper  }:



stdenv.mkDerivation rec {

  name = luakit-${version};

  version = 2012;



  src = fetchurl {

url = 
 https://github.com/mason-larobina/luakit/archive/${version}.tar.gz;;

sha256 = ...;

  };


  buildInputs = [ makeWrapper gtk libsoup pkgconfig webkit ];



  makeFlags = [ PREFIX=$(out) ];



  postInstall = ''

wrapProgram $out/bin/luakit \

  --prefix GIO_EXTRA_MODULES : ${glib_networking}/lib/gio/modules
 \

  --prefix XDG_DATA_DIRS : ${gsettings_desktop_schemas}/share

  '';



  meta = {

description = A Vim-like browser;

longDescription = ''

  A fast and lightweight vim like web browser based on the webkit
 web
  browser engine and the lua toolkit. luakit is keyboard driven
 and can be extended through the use of lua code.

   '';

   homepage = http://www.luakit.org;;

   license = stdenv.lib.licenses.gpl3;

   maintainers = [ stdenv.lib.maintainers.rickynils ];

   platforms = with stdenv.lib.platforms; linux;

 };

   }

 I then edited pkgs/top-level/all-packages.nix and it looks like this:


  luakit = callPackage ../applications/networking/browsers/luakit {
  inherit (gnome) libsoup;
  webkit = webkit_gtk2;
  };


 I then ran the command nix-build -A luakit

 and I get the error error: cannot auto-call a function that has an
 argument without a default value (`stdenv')


 I am not new to Linux but new to this type of package development.  I
 did read the other emails and posts made by others who have had this
 same problem as me, but I when I tried to do as they do I still got
 the message.  If someone could help a noob I would appreciate it.

 ~Thank you
 ___
 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] Maintainership

[Alex Berg]

Rather than removing unmaintained packages, can we make them available as a
separate, opt-in channel?
On Jan 28, 2014 6:43 PM, Jan Malakhovski o...@oxij.org wrote:

 On Tue, 28 Jan 2014 10:36:39 -0500
 Shea Levy s...@shealevy.com wrote:

  Thoughts? If we did decide this was a good idea, we should set aside
  some time period by which people should unmaintain packages they don't
  want this responsibility for and adopt packages they do.

 For what it worth, I think unmaintained packages should not be removed
 just for the sake of it, especially when/if their nix-expressions are
 nontrivial.

 Suppose currently I'm the only user (or even maybe ex-user) of a
 package, the package is some obscure userspace util and so there
 aren't any security concerns involved, it works (or even maybe
 worked) for me, but I don't have any time whatsoever to maintain it.

 * First, this remove unmaintained policy discourages adding new
 packages to the public nixpkgs by users that are unable to maintain
 stuff. In the example above, I would better store the package in my
 own branch than risk it being unexpectedly removed. This would
 probably imply duplication of work in case somebody else will want to
 have it at some later point. I wouldn't search all the nixpkgs' forks
 for a possibility that somebody already has an expression for this
 package.
 * Second, I believe making a broken package work is usually easier
 than writing the nix-expression from scratch. Searching repository
 history for old removed versions of nix-expressions would be painful.

 I would rather drop this remove unmaintained altogether, at least
 for current requirements for being a maintainer (especially about the
 timely fashion). Marking unmaintained (or even better: unmaintained
 and potentially exploitable (which I would define as: it's a daemon or
 some other package uses it)) packages broken and notifying
 contributors about this fact looks okay.

 Cheers,
   Jan
 ___
 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] how to overwrite a derivation in nix

[Alex Berg]

I've got a page on this topic in the wiki tree I'm working on. Maybe it can
help you.

https://nixos.org/wiki/Nix_Modifying_Packages

Let me know if it's missing your use-case, I'll try to add to it.
On Jan 10, 2014 5:57 AM, Marc Weber marco-owe...@gmx.de wrote:

 option 1: use ~/.nixpkgs/config.nix, see wiki how to keep multiple
 packages up to date or such.

 option 2: use applyGlobalOverrides
 problem: its not exposed by pkgs AFAIK

 option 3: when importing nipkgs pass config.nix (like option 1)

 option 4: use deepOverride (see lib.misc.nix)

 Then it would look like
 something_having_thunar_as_dep.deepOverride  {
   thunar = patch-thunar-here
 }

 Now it looks like you don't want to override, instead you want to
 reuse a build and add a patch only giving it a new name, this is done by
 overrideDerivation found in lib/customization.nix

 thunar is in xfce/core/thunar, and no top-level in all-packages.nix
 and eg ./pkgs/desktops/xfce/core/xfdesktop.nix|2| depends on it.

 Thus you might need any of the deep overriding methods listed above if
 you want packages to change depending on it.

 Eventually the most simple thing is to create a git topic branch and
 just apply your change.

 Marc Weber
 ___
 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] A generic wrapper method (possibly)

[Alex Berg]

I am interested in this topic. I don't completely understand the problem
here, but maybe I can help by discussing it.

The motivation for the addition of runtimeInputs is primarily to support
language interpreters and their libraries?

I really don't like to use wrapper, this term. I feel that it's a term
used when the problem isn't well understood and the solution is lazily
designed. If we can rewrite this concept using an attribute which has a
better name, this would definitely be a good change.

First, I would like to better understand the concept. How do you want to
use these runtimeInputs? You want to add them to an environment variable,
such as PATH, and keep this value after the build environment closes? Or
you want to modify the interpreter's package by adding symlinks to this
buildInputs packages?

Currently, buildInputs packages are built before the package, and their
bin, lib, and include directories are added to certain environment
variables so other tools can find them, but only during the build. Am I
wrong, or does it do other important things? (If there's documentation that
fully explains the effects of adding a package to this attribute, please
link me.)

Also, I remember that propagatedBuildInputs also exists. I don't
understand its exact purpose, but I believe it shares environment variables
between dependencies, from child to parent packages. Is runtimeInputs
similar?




On Sun, Dec 1, 2013 at 5:12 AM, Bjørn Forsman bjorn.fors...@gmail.comwrote:

 Hi all,

 For a long time I've been annoyed by the side effects of wrapping
 programs. Now I want to fix it.

 Wrapping programs makes the help text (very often) ugly: usage:
 .prog-wrapped some-option instead of usage: prog some-option.
 Whenever I see such help texts I cannot help but think that our
 current solution is very hacky. But the most important side effect is
 that some programs actually break when wrapped, because their argv[0]
 is different than it normally is; it has gotten a '.' in front and
 '-wrapped' at the end. I've seen this breakage in dblatex (IIRC) and
 munin (100% sure).

 What can we do about it?

 Peter Simons recently rewrote the python wrapper so that the python
 interpreter itself finds its dependencies instead of having to going
 through a different shell script that sets PYTHONPATH for it. (Well
 actually, there is a shell script involved, but it's different.)

 I have this idea that we can do a similar thing for other interpreters
 like sh, perl etc. My goal is to have wrapped interpreters instead
 of the current wrapper scripts around programs that use plain
 interpreters. (Of course, I don't think that we can stop using
 wrapProgram alltogether, but the common stuff I think we can make
 better.)

 I envision the end result to be something like this:

 stdenv.mkDerivation {
   name = foo-0.1;
   ...
   buildInputs = [ python pythonPackages.jedi ];
   runtimeInputs = [ python pythonPackages.jedi ];
   ...
 }

 (The use of python above is arbitrary. You could for instance replace
 it with bash + some deps that should be found in PATH.)

 The above derivation, when built, would construct a wrapped instance
 of the python interpreter which knows where to find the jedi package.
 And this interpreter would be used in the patchShebangs function.
 Automatically.

 What do you think? Does this sound like a good idea?

 As a start I've made a bash-wrapper (basically a copy of the python
 wrapper.nix file) to try fixing the munin package plugins. I'm now
 pondering how to to implement the runtimeInputs functionality. I
 imagine that the stdenv builder would have to be extended with hooks
 so that if bash in runtimeInputs then build bash-wrapper and if
 python in runtimeInputs then build python-wrapper. And patchShebangs
 must have these wrapped interpreters first in PATH.

 But this is where it stops for me. I have no idea how to implement if
 bash in runtimeInputs then build bash-wrapper and put that wrapper
 first in PATH. Any hints appreciated.

 Also if anyone thinks this runtimeInputs thing is a bad idea, please
 say so. And explain why :-)

 Best regards,
 Bjørn Forsman
 ___
 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] How to use Generated Rubygems Nix Packages?

[Alex Berg]

Wow, awesome answer! I never understood what the -P option claimed to do,
so I never tried it. It's super-useful! Thanks for teaching it!

I used that attribute in my buildInputs, and my app seems to have that
Gem available in its nix-shell.

Super awesome - thanks Bjorne!
On Nov 30, 2013 5:34 PM, Bjørn Forsman bjorn.fors...@gmail.com wrote:

 Hi Alex,

 On 30 November 2013 07:03, Alex Berg chex...@gmail.com wrote:
  I'm looking at the ruby/generated.nix file:
 
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/ruby/generated.nix
 
  Does anyone know how to add these Gems as a package's dependencies? I
 can't
  find any documentation or examples.
 
  I read the code and I tried many different attributes, but I can't figure
  out how to add these Nix expressions to add Gems as buildInputs to my
 app's
  Nix expression. I tried pkgs.gems.bundler and a few other attribute
 paths,
  but nothing works.

 Here is one way to find the attribute (the only way I know apart from
 reading and fully understanding all the related expressions):

 $ nix-env -qaP | grep bundler
 nixos.pkgs.rubyLibs.bundler
 ruby-bundler-1.3.5

 So rubyLibs.bundler is the attribute you're looking for.

 Best regards,
 Bjørn Forsman

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

[Nix-dev] How to use Generated Rubygems Nix Packages?

[Alex Berg]

I'm looking at the ruby/generated.nix file:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/ruby/generated.nix

Does anyone know how to add these Gems as a package's dependencies? I can't
find any documentation or examples.

I read the code and I tried many different attributes, but I can't figure
out how to add these Nix expressions to add Gems as buildInputs to my app's
Nix expression. I tried pkgs.gems.bundler and a few other attribute
paths, but nothing works.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Packaging Foreman

[Alex Berg]

As part of the Heroku Toolbelt, I need to make a Nix package for Foreman. I
am following the instructions to Install from Source [1]. The instructions
say that it has many package requirements:

gcc-c++ git libvirt-devel mysql-devel pg-devel openssl-devel \
libxml2-devel sqlite-devel libxslt-devel zlib-devel readline-devel \
postgresql-devel

Am I right when I say - If I want to package Foreman, I must first package
all these dependent packages. ?

Related question: Does anyone know how to use the auto-generated Gem
packages? I can't find any docs. -
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/ruby/generated.nix


[1] http://theforeman.org/manuals/1.3/index.html#3.4InstallFromSource
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Packaging Foreman

[Alex Berg]

Awesome, that's exactly the info I needed. I added those as dependencies
and now I'm making progress again. Now I'm working through a Ruby issue
(Gem::RemoteFetcher::FetchError).

For curious readers, here's how I did that.

### foreman/default.nix ###
{ stdenv, fetchurl, rubygems, gcc, git, libvirt, mysql,
  postgresql, openssl, libxml2, sqlite, libxslt, zlib, readline
}:

stdenv.mkDerivation rec {

  name = foreman;

  src = fetchurl {
# Tarball link fetched from here:
http://projects.theforeman.org/projects/foreman/files
url = 
http://projects.theforeman.org/attachments/download/642/foreman-1.3.1.tar.bz2
;
sha256 = 0jq48nswwgx7lk79cpdm2zmn40rxf1jjnng63qmam09m4pbypj3r;
  };

  buildInputs = [ rubygems gcc git libvirt mysql
  postgresql openssl libxml2 sqlite libxslt zlib readline ];
...


On Tue, Nov 19, 2013 at 5:17 PM, Oliver Charles ol...@ocharles.org.ukwrote:

 On 11/19/2013 09:03 AM, Alex Berg wrote:
 
  As part of the Heroku Toolbelt, I need to make a Nix package for
  Foreman. I am following the instructions to Install from Source [1]. The
  instructions say that it has many package requirements:
 
  gcc-c++ git libvirt-devel mysql-devel pg-devel openssl-devel \
  libxml2-devel sqlite-devel libxslt-devel zlib-devel
 readline-devel \
  postgresql-devel
 
  Am I right when I say - If I want to package Foreman, I must first
  package all these dependent packages. ?

 I don't know Foreman, but yes - you will need all of those dependencies.
 Note however that these dependencies seem to be specified as Ubuntu
 package names. We don't strip out include files from our packages, so we
 don't have 'devel' versions. Thus a lot of these dependencies we
 probably already have:

 gcc-c++ - gcc
 mysql-devel - mysql
 pg-devel - postgresql9*
 sqlite-devel - sqlite

 etc.

 I tend to grep in nixpkgs/pkgs/top-level/all-packages.nix for the
 start of the expression, find something that looks relevant, add it to
 the expression of whatever I'm packaging, and attempt to nix-build. I
 repeat that process until all dependencies are satisfied

  Related question: Does anyone know how to use the auto-generated Gem
  packages? I can't find any docs. -
 
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/ruby/generated.nix

 This really needs better documentation. Most people will tell you to
 read nixpkgs/pkgs/development/interpreters/ruby/rubygems.nix, but imo
 that is not good enough.

 - ocharles


 ___
 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] How to package Heroku Toolbelt?

[Alex Berg]

Thanks for the idea Jonas. I gave it a try, and I finally got it working.
But, I encountered some problems on the way, so I want to ask here.

I am using Ruby 1.9, which includes Rubygems out-of-the-box, I believe.

$ gem install heroku
ERROR:  While executing gem ... (Gem::FilePermissionError)
You don't have write permissions into the
/nix/store/m1mgqmkx23hyqr8sp1533x4mhcv6fpqf-ruby-1.9.3-p429/lib/ruby/gems/1.9.1
directory.

We can't install stuff into a Nix Store, so I must install Gems into a
directory which I own. I discovered I can override the default Gem location
by setting the GEM_HOME environment variable, so I chose my home
directory, which I own.

$ export GEM_HOME=/home/chexxor/.gemrepo
$ gem install heroku
# No problem
$ heroku
# Nothing. The PATH doesn't point there. How should I manage the PATH?
$  ~/.gemrepo/gems/heroku-3.0.1/bin/heroku
# Same readline error as from my Nix-packaged Heroku

So, installing the heroku Gem produced the same result as installing the
heroku Nix package. But, I found a way to fix the issue.

$ gem install rb-readline
$ heroku
# Heroku command list - Success!

How is rb-readline Gem different from the readline package which is
installed when Nix-packaged Ruby is installed? I read the docs, which say
that rb-readline is a Ruby implementation of the readline package,
which is written in C. The rb-readline package works easier across more
platforms. (Is this a bug in the Ruby Nix package?)

Some questions:

1) Where should NixOS users store Gems? I believe Gems are dependent on a
specific Ruby version, so we should ensure each Ruby version gets its own
set of Gems. No?
2) Does anybody else have this readline issue? Can we define this
rb-readline Gem as a dependency of the Ruby Nix package?






On Mon, Nov 18, 2013 at 6:59 AM, Jonas Pfenniger (zimbatm) 
zimb...@zimbatm.com wrote:

 Alternatively you could also just install the heroku and the foreman
 gem for the same effect.
 The toolbelt is really just a distribution of these gems with a bundled
 ruby interpreter, it's principally meant for OSes with a broken package
 management like OSX and Windows (they want to avoid support for
 mis-configured ruby installs).


 On 15 November 2013 07:24, Vladimír Čunát vcu...@gmail.com wrote:

 On 11/15/2013 06:34 AM, Alex Berg wrote:

 Now, another question. After I install the Heroku Toolbelt, the `heroku`
 command is available on the command-line. But, I can't run it because I
 haven't installed Ruby.


 That's because of not patching the shebangs. You are right that it's run
 automatically, but you just need to add ruby to buildInputs, so it's found
 by the patcher. (I confused this, direct running of patchShebangs is only
 needed if the builders need to run scripts.)

 However, it still complains about some dependencies. I would just have to
 guess how this is best done, as I don't know ruby. You can try looking at
 other packages using it (git grep ruby), or hopefully someone with nix+ruby
 experience will help (e.g. I saw ToDo on wiki from Marc Weber 
 marco-owe...@gmx.de).


 Good luck!
 Vlada



 ___
 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] How to package Heroku Toolbelt?

[Alex Berg]

Yes --user-install option[1] will install Gems into my home directory.
(Related: Bundler can also do this, with the --path option. [2]) But,
should storing gems in Home directory be the default behavior for Ruby on
NixOS? If so, we should configure this when installing Ruby or Rubygems. We
I see two options for this configuration: 1) Set GEM_HOME in load script
for shell, such as `.bashrc`, and 2) Create `.gemrc` file [3] and put
gem-install: --user-installin it.

I'll try to reinstall Ruby with the cursesSupport option and then update
you.

Here's my `gem env` info for you. Note that, after I set the GEM_HOME
environment variable, the priority of the Nix Store path was lowered, to
become:
   - $GEM_HOME
   - /home/chexxor/.gem/ruby/1.9.1
   -
/nix/store/m1mgqmkx23hyqr8sp1533x4mhcv6fpqf-ruby-1.9.3-p429/lib/ruby/gems/1.9.1


$ GEM_HOME
$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.8.17
  - RUBY VERSION: 1.9.3 (2013-05-15 patchlevel 429) [x86_64-linux]
  - INSTALLATION DIRECTORY:
/nix/store/m1mgqmkx23hyqr8sp1533x4mhcv6fpqf-ruby-1.9.3-p429/lib/ruby/gems/1.9.1
  - RUBYGEMS PREFIX:
/nix/store/b2f6h37xaqx8nvnl9sib3hgwp3r7f91h-rubygems-1.8.17
  - RUBY EXECUTABLE:
/nix/store/m1mgqmkx23hyqr8sp1533x4mhcv6fpqf-ruby-1.9.3-p429/bin/ruby
  - EXECUTABLE DIRECTORY:
/nix/store/m1mgqmkx23hyqr8sp1533x4mhcv6fpqf-ruby-1.9.3-p429/bin
  - RUBYGEMS PLATFORMS:
- ruby
- x86_64-linux
  - GEM PATHS:
 -
/nix/store/m1mgqmkx23hyqr8sp1533x4mhcv6fpqf-ruby-1.9.3-p429/lib/ruby/gems/1.9.1
 - /home/chexxor/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
 - :update_sources = true
 - :verbose = true
 - :benchmark = false
 - :backtrace = false
 - :bulk_threshold = 1000
  - REMOTE SOURCES:
 - http://rubygems.org/


[1] http://guides.rubygems.org/command-reference/#gem_install
[2] http://bundler.io/v1.5/man/bundle-install.1.html
[3] http://guides.rubygems.org/command-reference/#gem_environment



On Mon, Nov 18, 2013 at 7:17 PM, Jonas Pfenniger (zimbatm) 
zimb...@zimbatm.com wrote:

 What's the output of `gem env` if you unset the GEM_HOME that you have
 exported ?
 Normally you should have $HOME/.gem/ruby/1.9.1 in your gem paths and `gem
 install --user-install your-gem` should place it there. You still have to
 add $HOME/.gem/ruby/1.9.1/bin in your PATH.
 Later versions of rubygems automatically place gems in the first writable
 gem path. 1.9.1 is not the version of ruby but the version of the stdlib.

 I'm super new to Nix so please correct me if I'm wrong. My understanding
 is that you could as well manage your ruby dependencies using nix and the
 nix gem. See:
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/ruby/generated.nix.
  I don't have an exact howto but I believe you could generate another .nix
 expression with the dependencies that you want using that gem ?

 Regarding readline, it seems that it's only compiled if a cursesSupport
 flag is enabled :
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/ruby/ruby-19.nix#L5but
  I don't know how to compile ruby with it or not. You could check by
 running `find /nix/store/
 m1mgqmkx23hyqr8sp1533x4mhcv6fpqf-ruby-1.9.3-p429/ -name readline.so`.
 Usually it live be under lib/ruby/1.9.1/x86_64-linux.



 On 18 November 2013 08:08, Alex Berg chex...@gmail.com wrote:

 Thanks for the idea Jonas. I gave it a try, and I finally got it working.
 But, I encountered some problems on the way, so I want to ask here.

 I am using Ruby 1.9, which includes Rubygems out-of-the-box, I believe.

 $ gem install heroku
 ERROR:  While executing gem ... (Gem::FilePermissionError)
 You don't have write permissions into the
 /nix/store/m1mgqmkx23hyqr8sp1533x4mhcv6fpqf-ruby-1.9.3-p429/lib/ruby/gems/1.9.1
 directory.

 We can't install stuff into a Nix Store, so I must install Gems into a
 directory which I own. I discovered I can override the default Gem location
 by setting the GEM_HOME environment variable, so I chose my home
 directory, which I own.

 $ export GEM_HOME=/home/chexxor/.gemrepo
 $ gem install heroku
 # No problem
 $ heroku
 # Nothing. The PATH doesn't point there. How should I manage the
 PATH?
 $  ~/.gemrepo/gems/heroku-3.0.1/bin/heroku
 # Same readline error as from my Nix-packaged Heroku

 So, installing the heroku Gem produced the same result as installing
 the heroku Nix package. But, I found a way to fix the issue.

 $ gem install rb-readline
 $ heroku
 # Heroku command list - Success!

 How is rb-readline Gem different from the readline package which is
 installed when Nix-packaged Ruby is installed? I read the docs, which say
 that rb-readline is a Ruby implementation of the readline package,
 which is written in C. The rb-readline package works easier across more
 platforms. (Is this a bug in the Ruby Nix package?)

 Some questions:

 1

Re: [Nix-dev] How to package Heroku Toolbelt?

[Alex Berg]

Thanks Vlad!

I added the following attribute in the `top-level/all-packages.nix` file,
right below the `ruby` attribute.

rubyCurses = ruby.override { cursesSupport = true; };

Then I reinstalled Ruby and found success. Nice!

$ nix-env --uninstall ruby
$ nix-env --uninstall rubygems
$ nix-env --install -A rubyCurses -f
/my-sources/pkgs/top-level/all-packages.nix
$ sudo nix-env --install -A heroku-toolbelt -f
/my-sources/pkgs/top-level/all-packages.nix
$ heroku
# Heroku command list - Success!

Two final questions:

1) Why is cursesSupport disabled by default? Does it not work on most
systems? If a relatively popular package like Heroku requires readlike,
which requires curses, I believe Ruby should have this functionality
out-of-the-box.

2) I will rename this package from heroku-toolbelt to just heroku,
because it doesn't include foreman or anything else. Can I make a wrapper
package called heroku-toolbelt, which installs heroku, foreman and
git?





On Tue, Nov 19, 2013 at 2:33 AM, Vladimír Čunát vcu...@gmail.com wrote:

 On 11/18/2013 12:17 PM, Jonas Pfenniger (zimbatm) wrote:

 Regarding readline, it seems that it's only compiled if a cursesSupport
 flag is enabled :
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/
 development/interpreters/ruby/ruby-19.nix#L5
 but I don't know how to compile ruby with it or not


 That can be done via a simple override:

 rubyCurses = ruby.override { cursesSupport = true; };


 Vlada



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

Re: [Nix-dev] how much disk do I need ?

[Alex Berg]

I was playing with NixOS a few weeks ago. I installed KDE, a web server,
and some other packages. I ran out of disk space at 8 gigs, so I would
suggest 16+ gigs. How much RAM is required? 4 GB should be fine. Anyone
disagree? This is just a nontechnical answer, but useful as a first reply.
On Nov 16, 2013 4:32 AM, Roelof Wobben rwob...@hotmail.com wrote:

 Hello,

 With the help of Bjorn I want to try to make Cinnamon 2.x avaible.

 But my question is

 How big must the partition be to install NixOS and have space for
 building Cinnamon.

 I have 4G memory. Do I still need a swap partition.

 Roelof
 ___
 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] Help Testing New Package

[Alex Berg]

Awesome, I finally got it working with this command. (I'm working on a new
package now.)

nix-build /my-sources/pkgs/top-level/all-packages.nix -A heroku-toolbelt

Thanks Marc!


On Wed, Nov 13, 2013 at 9:09 AM, Marc Weber marco-owe...@gmx.de wrote:

 Excerpts from Alex Berg's message of Wed Nov 13 01:59:24 +0100 2013:
  How can I test the package I created in my fork of NixPkgs?
 nix-build -A name location-of-your-fork/ (default.nix will be used which
 loads all-packages.nix)

 Marc Weber
 ___
 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] How to package Heroku Toolbelt?

[Alex Berg]

How do I package the Heroku Toolbelt? -
https://toolbelt.heroku.comhttps://toolbelt.heroku.com/install.sh

It looks like the Ubuntu installer includes Ruby and some other stuff, so I
think I should just package the Standalone option. This option tells me
to download and run a shell script - https://toolbelt.heroku.com/install.sh

Question 1: Should I copy-paste this shell script into the
heroku-toolbelt package, then use the builder attribute to call this?
Or should I use the the standard builder by using the src attribute to
download the tarball?

Question 2: If the latter,  where should I get the tarball?
From the URL in that shell script? -
https://s3.amazonaws.com/assets.heroku.com/heroku-client/heroku-client.tgz
Or from their GitHub repo? https://github.com/heroku/heroku

My progress:
I am assuming I should not use that shell script, because Nix was designed
to do the same thing, but better.

The Heroku Toolbelt is a Ruby script, I believe, so there's no compilation,
I just need to ensure my PATH has this Nix Store derivation.

So, I believe I only need the unpack phase, but I don't know how to make it
do only the unpack.

My problem:
I've read the docs, but I still have problems. I don't know what is in
context in various places, what each phase should be doing, etc.

Question 3:
I get an error, but I don't know what it means. Can someone translate this
for me?


Here is the package I've got so far, and the error.


stdenv.mkDerivation rec {
  name = heroku-toolbelt;

  src = fetchurl {
url = 
https://s3.amazonaws.com/assets.heroku.com/heroku-client/heroku-client.tgz;;
sha256 = 00zqj9jwcklfyq5k3v81dwlzrrjm8axkgx7mixcb1kghjjlsdzv2;
#url = https://toolbelt.heroku.com/install.sh;;
#sha256 = 10i5wgqfka6yifh6p4hmvzvfkm0k1w4s59fwz3vip3knpyi6abcz;
  };

  nativeBuildInputs = [  ];

  #builder = ${src}/install.sh;

  #configurePhase = ;
  #buildPhase = ;
  #installPhase = mv heroku-client/* .; rmdir heroku-client; ;
  #installPhase = ;

  phases = [ unpackPhase ];
}


[chexxor@nixos:~]$ nix-build /my-sources/pkgs/top-level/all-packages.nix -A
heroku-toolbelt
these derivations will be built:
  /nix/store/226khb1zh9kb94wwc27as2kxiyrqmqkj-heroku-toolbelt.drv
building path(s)
`/nix/store/ibh9r574dd14wd01xpmldy90c69z8lfh-heroku-toolbelt'
building /nix/store/ibh9r574dd14wd01xpmldy90c69z8lfh-heroku-toolbelt
unpacking sources
punpacking source archive
/nix/store/dfryky194z2bv179pd4jf3ny2gn9di02-heroku-client.tgz
source root is heroku-client
builder for
`/nix/store/226khb1zh9kb94wwc27as2kxiyrqmqkj-heroku-toolbelt.drv' failed to
produce output path
`/nix/store/ibh9r574dd14wd01xpmldy90c69z8lfh-heroku-toolbelt'
error: build of
`/nix/store/226khb1zh9kb94wwc27as2kxiyrqmqkj-heroku-toolbelt.drv' failed
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How to package Heroku Toolbelt?

[Alex Berg]

Excellent! I've got it working now. For the curious ones, I pasted my
successful package below.

Now, another question. After I install the Heroku Toolbelt, the `heroku`
command is available on the command-line. But, I can't run it because I
haven't installed Ruby.

Question 4: Is there some way to tell Nix that Ruby is a run-time
dependency of this package, and it should install the `ruby` package?

If that's the wrong idea, I want to know why. Is it that, each `nix-env
--install` command should expose only one application? I agree that Ruby is
an app, but is Heroku Toolbelt an app? The Toolbelt is just a Ruby script,
which is useless without Ruby. So...installing the Toolbelt should also
install Ruby, right? Help me understand the logic here.

Question 5: Why must I specify the patchShebangs function? The NixPkgs
manual says the fixupPhase does this automatically. It rewrites the
interpreter paths of shell scripts to paths found in PATH.
See NixPkgs Manual: 3.4.8. The Fixup Phase:
http://nixos.org/nixpkgs/manual/#idp638240




stdenv.mkDerivation rec {
  name = heroku-toolbelt;

  src = fetchurl {
url = 
https://s3.amazonaws.com/assets.heroku.com/heroku-client/heroku-client.tgz;;
sha256 = 00zqj9jwcklfyq5k3v81dwlzrrjm8axkgx7mixcb1kghjjlsdzv2;
  };

  # The heroku command is a Ruby script, so do we need to include `ruby`
here?
  # Ruby isn't necessary to build it, so why include it in the
BuildInputs?
  #nativeBuildInputs = [ ruby ];

  installPhase =  mkdir -p $out; mv ./* $out; ;
  # The docs say the fixupPhase does this. Can I just use that?
  #postInstall = patchShebangs $out;;

  phases = [ unpackPhase installPhase fixupPhase ];

  meta = { snip };
}



On Thu, Nov 14, 2013 at 5:57 PM, Vladimír Čunát vcu...@gmail.com wrote:

 On 11/14/2013 10:44 AM, Alex Berg wrote:

 [chexxor@nixos:~]$ nix-build /my-sources/pkgs/top-level/all-packages.nix
 -A heroku-toolbelt
 these derivations will be built:
/nix/store/226khb1zh9kb94wwc27as2kxiyrqmqkj-heroku-toolbelt.drv
 building path(s)
 `/nix/store/ibh9r574dd14wd01xpmldy90c69z8lfh-heroku-toolbelt'
 building /nix/store/ibh9r574dd14wd01xpmldy90c69z8lfh-heroku-toolbelt
 unpacking sources
 punpacking source archive
 /nix/store/dfryky194z2bv179pd4jf3ny2gn9di02-heroku-client.tgz
 source root is heroku-client
 builder for
 `/nix/store/226khb1zh9kb94wwc27as2kxiyrqmqkj-heroku-toolbelt.drv' failed
 to produce output path
 `/nix/store/ibh9r574dd14wd01xpmldy90c69z8lfh-heroku-toolbelt'
 error: build of
 `/nix/store/226khb1zh9kb94wwc27as2kxiyrqmqkj-heroku-toolbelt.drv' failed


 The error just means that the builder didn't create anything in the output
 path (passed in $out variable). But it doesn't seem you even wanted to do
 that yet ;-)

 Q1: the script can't be used as it is, because it installs into wrong
 paths (/usr/local/...).

 Q2: the source of the tarball doesn't really matter. It needs to always
 have the same hash. (You can even specify multiple sources, for the case
 that some are unavailable.)


 If the program is a ruby script, then you need to patch its shebang to use
 ruby from nix store and not #!/usr/bin/ruby. For that it should be enough
 to have postInstall = patchShebangs $out; with ruby in buildInputs and
 assuming you get the scripts into $out in installPhase.


 Vlada



 ___
 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] Help Testing New Package

[Alex Berg]

I am trying to make a new package in my fork of NixPkgs.

Steps taken:
- Copy similar package (sublime-text-2 to create sublime-text-3)
- Update a few values

Now, I want to test this package. I read on the wiki that I should be able
to use nix-build -A libfoo, but this is not working for me.

Here's the command I'm using and the error:

 nix-build -A sublime-text-3 --dry-run -I nixpkgs=/my-sources -vvv
# error: getting status of `/home/chexxor/default.nix': No such
file or directory

How can I test the package I created in my fork of NixPkgs?

Here's a complete log of my project until now:

https://bitbucket.org/chexxor/researchnotes/src/7f763a48c303e79fea1a1b751b038d581ae4bda1/CodeArticles/InstallingDevelopmentToolsWithNix.md
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev