[Nix-dev] Bundling nix-expressions with source code

2013-01-22 Thread Rickard Nilsson
Hi,

I would like to bundle nix-expressions with some of my self-developed  
programs, and just let nixpkgs (or some custom-nixpkgs) use the  
nix-expression from the source when building the program. Is this a wise  
thing to do? Is it even possible?

A pseudo-example:


nixpkgs:
...

   myprog_src = fetchgit { ... };

   myprog = callPackage "${myprog_src}/default.nix" { };

...


default.nix:

{ stdenv, foo, bar }:

stdenv.mkDerivation = {
   src = ./;
   buildInputs = [ foo bar ];
}


Obviously, the above example does not work. But can something similar,  
that actually works, be written in nix? Or must one always separate the  
package definition (nix mkDerivation expression) and the source?


Best regards,
   Rickard Nilsson
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Bundling nix-expressions with source code

2013-01-22 Thread Marc Weber
Excerpts from Rickard Nilsson's message of Tue Jan 22 13:05:09 +0100 2013:
> I would like to bundle nix-expressions with some of my self-developed  
> programs, and just let nixpkgs (or some custom-nixpkgs) use the  
> nix-expression from the source when building the program. Is this a wise  
> thing to do? Is it even possible?
Why not?

You can always build using external files like this:

  let pkgs  = import /etc/nixos/nixpkgs {};
  in {
pkgs.mkDerivation {
  ./your-source-whatsoever
}
  }

The only issue if you have multiple packages depending on each other.

Usually whatever works is good :)

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


Re: [Nix-dev] Bundling nix-expressions with source code

2013-01-22 Thread Eelco Dolstra
Hi,

On 22/01/13 13:05, Rickard Nilsson wrote:

> I would like to bundle nix-expressions with some of my self-developed  
> programs, and just let nixpkgs (or some custom-nixpkgs) use the  
> nix-expression from the source when building the program. Is this a wise  
> thing to do? Is it even possible?

It's possible but unfortunately not a good idea.  Doing this:

>myprog_src = fetchgit { ... };
> 
>myprog = callPackage "${myprog_src}/default.nix" { };

in Nixpkgs means that an operation like "nix-env -qa '*'" will need to build
myprog_src first, which won't work because query operations open the Nix store
in read-only mode.

OTOH, if you just want to use Nixpkgs inside another project, like Marc said,
you can just do something like:

  with import  {};

  stdenv.mkDerivation {
name = "my-pkg";
src = ./.;
buildInputs = [ qt4 ... ];
  };

> Obviously, the above example does not work. 

It actually does work in some cases, e.g. "nix-build -A myprog" should work.

-- 
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] Bundling nix-expressions with source code

2013-01-24 Thread Rickard Nilsson
Den 2013-01-22 14:51:24 skrev Eelco Dolstra :

> Hi,
>
> On 22/01/13 13:05, Rickard Nilsson wrote:
>
>> I would like to bundle nix-expressions with some of my self-developed
>> programs, and just let nixpkgs (or some custom-nixpkgs) use the
>> nix-expression from the source when building the program. Is this a wise
>> thing to do? Is it even possible?
>
> It's possible but unfortunately not a good idea.  Doing this:
>
>>myprog_src = fetchgit { ... };
>>
>>myprog = callPackage "${myprog_src}/default.nix" { };
>
> in Nixpkgs means that an operation like "nix-env -qa '*'" will need to  
> build
> myprog_src first, which won't work because query operations open the Nix  
> store
> in read-only mode.

OK, I see why that is not feasible. The reason I ask, is that it seems
reasonable that a Nix-aware upstream package developer should be able
to define how the package should be built (dependencies, build flags etc),
in tandem with the package development itself.

I imagine that you in some way could define package names, versions,
source url, source checksum and other metadata in nixpkgs, and then
pick buildInputs, configureFlags etc from the source. But that is
more or less what we do today anyway, with the difference that we
pick a configure-script and a Makefile from the source instead of
Nix-expressions.


Best regards,
   Rickard Nilsson
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Bundling nix-expressions with source code

2013-01-24 Thread Vladimír Čunát

On 01/24/2013 04:13 PM, Rickard Nilsson wrote:

OK, I see why that is not feasible. The reason I ask, is that it seems
reasonable that a Nix-aware upstream package developer should be able
to define how the package should be built (dependencies, build flags etc),
in tandem with the package development itself.

I imagine that you in some way could define package names, versions,
source url, source checksum and other metadata in nixpkgs, and then
pick buildInputs, configureFlags etc from the source. But that is
more or less what we do today anyway, with the difference that we
pick a configure-script and a Makefile from the source instead of
Nix-expressions.


I see nix is getting quite popular :-)
The maintainer is of course welcome to maintain also the nix expression 
*within* nixpkgs, who else is a better candidate...



Vlada



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] Bundling nix-expressions with source code

2013-01-25 Thread Rickard Nilsson
Den 2013-01-24 23:01:03 skrev Vladimír Čunát :

> On 01/24/2013 04:13 PM, Rickard Nilsson wrote:
>> OK, I see why that is not feasible. The reason I ask, is that it seems
>> reasonable that a Nix-aware upstream package developer should be able
>> to define how the package should be built (dependencies, build flags  
>> etc),
>> in tandem with the package development itself.
>>
>> I imagine that you in some way could define package names, versions,
>> source url, source checksum and other metadata in nixpkgs, and then
>> pick buildInputs, configureFlags etc from the source. But that is
>> more or less what we do today anyway, with the difference that we
>> pick a configure-script and a Makefile from the source instead of
>> Nix-expressions.
>
> I see nix is getting quite popular :-)
> The maintainer is of course welcome to maintain also the nix expression
> *within* nixpkgs, who else is a better candidate...

Yes, absolutely, and that is completely OK. But you might want to keep
an in-development default.nix in the upstream repo, too. It's actually
very nice to use Nix during development, for handling dependencies,
installing throw-away stuff in your profile, etc.

Oh well, this is just me thinking out loud.

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


Re: [Nix-dev] Bundling nix-expressions with source code

2013-01-26 Thread Vladimír Čunát

On 01/25/2013 09:32 AM, Rickard Nilsson wrote:

Den 2013-01-24 23:01:03 skrev Vladimír Čunát :

I see nix is getting quite popular :-)
The maintainer is of course welcome to maintain also the nix expression
*within* nixpkgs, who else is a better candidate...


Yes, absolutely, and that is completely OK. But you might want to keep
an in-development default.nix in the upstream repo, too. It's actually
very nice to use Nix during development, for handling dependencies,
installing throw-away stuff in your profile, etc.

Oh well, this is just me thinking out loud.


I see the motivation now. Well, you can have a project-local nix file 
that imports its dependencies from the global expression - and you build 
it in the directory via "nix-build ./" (you probably don't want these 
things in your profile, maybe rather in a seprarate project-profile).


This way seems cleaner to me, because intuitively the project depends on 
nixpkgs, not the other way around. (You could also have e.g. a topgit 
branch for the project on top of nixpkgs, but it seems inferior to the 
solution above.)



Vlada




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] Bundling nix-expressions with source code

2013-01-28 Thread Eelco Dolstra
Hi,

On 25/01/13 09:32, Rickard Nilsson wrote:

>> I see nix is getting quite popular :-)
>> The maintainer is of course welcome to maintain also the nix expression
>> *within* nixpkgs, who else is a better candidate...
> 
> Yes, absolutely, and that is completely OK. But you might want to keep
> an in-development default.nix in the upstream repo, too. It's actually
> very nice to use Nix during development, for handling dependencies,
> installing throw-away stuff in your profile, etc.

Yes, I totally agree.  I have exactly that problem with packages like Hydra and
Charon, which have Nix expressions in their own trees to build them - which then
needs to be duplicated in Nixpkgs to make them available there :-(

-- 
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] Bundling nix-expressions with source code

2013-01-28 Thread Ludovic Courtès
Hi,

Eelco Dolstra  skribis:

> On 25/01/13 09:32, Rickard Nilsson wrote:
>
>>> I see nix is getting quite popular :-)
>>> The maintainer is of course welcome to maintain also the nix expression
>>> *within* nixpkgs, who else is a better candidate...
>> 
>> Yes, absolutely, and that is completely OK. But you might want to keep
>> an in-development default.nix in the upstream repo, too. It's actually
>> very nice to use Nix during development, for handling dependencies,
>> installing throw-away stuff in your profile, etc.
>
> Yes, I totally agree.  I have exactly that problem with packages like Hydra 
> and
> Charon, which have Nix expressions in their own trees to build them - which 
> then
> needs to be duplicated in Nixpkgs to make them available there :-(

In principle there could be just one expression in Nixpkgs, and the
package’s release.nix would just use ‘overrideDerivation’ to change the
‘src’ attribute of that expression to point to the result of the
‘tarball’ job.

WDYT?

Ludo’.

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


Re: [Nix-dev] Bundling nix-expressions with source code

2013-01-28 Thread Eelco Dolstra
Hi,

On 28/01/13 14:12, Ludovic Courtès wrote:

> In principle there could be just one expression in Nixpkgs, and the
> package’s release.nix would just use ‘overrideDerivation’ to change the
> ‘src’ attribute of that expression to point to the result of the
> ‘tarball’ job.

That would kind of work, but it's nicer to keep the expression in the same
repository as the source of the package.  That way they're always consistent.

-- 
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] Bundling nix-expressions with source code

2013-01-28 Thread Shea Levy
On 01/28/2013 10:14 AM, Eelco Dolstra wrote:
> Hi,
>
> On 28/01/13 14:12, Ludovic Courtès wrote:
>
>> In principle there could be just one expression in Nixpkgs, and the
>> package’s release.nix would just use ‘overrideDerivation’ to change the
>> ‘src’ attribute of that expression to point to the result of the
>> ‘tarball’ job.
> That would kind of work, but it's nicer to keep the expression in the same
> repository as the source of the package.  That way they're always consistent.
>

If only someone would extend nix to be able to query partial information 
about packages that would require building derivations to get full 
information ;)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev