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

[Thomas Hunger]

Hi,

Thanks. That was a lot to read and understand. I think my favourite
solution would be Shea's recursive-derivations branch.

Without that we're trying two different ways for keeping our dependencies
in the external repository:

1) Create a build.nix and use a custom builder instead of e.g.
buildPythonPackage.
2) Have a custom "import" builder which unpacks a source and throws away
everything other than .nix files. We can then import from that custom
builder (basically [1]).

Not sure which one we'll keep long term.

~

[1]
https://gist.github.com/teh/ad22d636e7cb3c4d89ee


On 18 March 2015 at 16:11, Shea Levy <shea at shealevy.com> wrote:

> See 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.
>
> ~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
>
>
> On 18 March 2015 at 16:01, Thomas Hunger <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> 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> 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>
>>> 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
>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>
>>> _______________________________________________
>>> nix-dev mailing list
>>> nix-dev at lists.science.uu.nl
>>> 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/20150322/4bc982e9/attachment.html