[Nix-dev] Question about organising dependencies not in core nixpkgs?

[Shea Levy]

See https://github.com/NixOS/nix/pull/213 <https://github.com/NixOS/nix/pull/213>. The comment chain is long, but it’s important to read up to https://github.com/NixOS/nix/pull/213#issuecomment-43674771 <https://github.com/NixOS/nix/pull/213#issuecomment-43674771>.

~Shea

> On Mar 18, 2015, at 12:02 PM, Thomas Hunger <tehunger at gmail.com> wrote:
> 
> Apologies, here's the rest of my email:
> 
> .. but I could not find anything that looks like "evaluate at build time" - is that code somewhere public?
> 
> Thanks,
> Tom
> 
> [1]
> https://github.com/shlevy/nix <https://github.com/shlevy/nix>
> 
> 
> On 18 March 2015 at 16:01, Thomas Hunger <tehunger at gmail.com <mailto:tehunger at gmail.com>> wrote:
> Hi Shea,
> 
> I checked your github version of nix [1]
> 
> 
> [1]
> 
> 
> On 18 March 2015 at 14:39, Shea Levy <shea at shealevy.com <mailto:shea at shealevy.com>> wrote:
> You can already do this. “import foo” will build any derivations that “foo” depends on at evaluation time.
> 
> Note though that really “build at evaluation time” is for several reasons inferior to “evaluate at build time”, i.e. recursive nix. I have an implementation for that but it doesn’t look like it will be accepted.
> 
> ~Shea
> 
>> On Mar 18, 2015, at 8:36 AM, Kirill Elagin <kirelagin at gmail.com <mailto:kirelagin at gmail.com>> wrote:
>> 
>> I’d say there is a more general problem.
>> 
>> Imagine, that one day [in a far far away future] people start shipping derivations in `default.nix` in their sources (I guess people who develop on NixOS/with nixpkgs already do this as they have the file for their build environment anyway, so why not commit it). And then we have two copies of derivations: in the source repository and in `nixpkgs`.
>> 
>> So it really looks like having something like `fetchDerivation("…url…")` would be handy. This function should fetch the source, unpack it, extract `default.nix` and use it as derivation to build the already fetched source. This way the `nixpkgs` repository itself is not required for packages that have this kind of information shipped and other projects can depend directly on the urls of repos. Then nixpkgs could be thought as a database of “well-known” packages with their urls.
>> 
>> On Wed, Mar 18, 2015 at 2:53 PM Luca Bruno <lethalman88 at gmail.com <mailto:lethalman88 at gmail.com>> wrote:
>> On 18/03/2015 12:37, Thomas Hunger wrote:
>> > Thanks.
>> >
>> > That would require having the shell.nix library locally already
>> > AFAICT. To rephrase slightly. Ideally I'd like to be able to do:
>> >
>> > myLibrary = fetchurl { ... };
>> > extraDepends = import "${myLibrary}/depends.nix";
>> > buildDepends = [ ... ] ++ extraDepends;
>> >
>> > Does that make sense?
>> I understand that, but I think the best fit of nix usage is having all
>> the nix expressions in the same repository, instead of spreading nix
>> files on every repository. That is, what's nixpkgs is doing.
>> 
>> So I would create a repo of all nix files, which fetch sources from your
>> other repos.
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev <http://lists.science.uu.nl/mailman/listinfo/nix-dev>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev <http://lists.science.uu.nl/mailman/listinfo/nix-dev>
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150318/dcf13728/attachment.html