[Nix-dev] How can we make import-from-derivation more useful?

[Daniel Peebles]

I might start by converting some of the Apple open source releases to use
import-from-derivation, if nobody objects. Should limit the impact to only
Darwin users, but I do think this needs to go more broadly.

Also, if any Nix gurus want to help me review Shea's ancient (but related
to this topic) pull request https://github.com/NixOS/nix/pull/52 (a more
recent attempt than #31 he linked to earlier in this thread), please do! If
we can get interest going again, I'd be happy to resolve conflicts and
resume pushing to get it merged. I'm brushing up on the Nix internals
needed to understand it, but I expect some of you won't need as much
preparation.


On Mon, Jan 4, 2016 at 4:30 AM, Ericson, John <john_ericson at brown.edu>
wrote:

> Shea's changes sound good, and I once wrote up a plan for making
> `--dry-run` play nicer with this https://github.com/NixOS/nix/issues/666
> . That said, I rather just start using import-from-derivation in nixpkgs
> immediately, and let the fallout be more motivation to improve nix. IMO,
> anybody using the eval-everything portions of nix-env is a masochist
> anyways :).
>
> On Mon, Dec 28, 2015 at 8:12 AM, Shea Levy <shea at shealevy.com> wrote:
>
>> https://github.com/NixOS/nix/pull/31 may be relevant.
>>
>> On 2015-12-28 11:10, Daniel Peebles wrote:
>> > A few days ago, I proposed importing from a derivation [1] to save us
>> > from having to manually manage autogenerated firefox/thunderbird
>> > fixed-output derivaiton hash files and junk up the nixpkgs repository
>> > with them. In response, Vladimír Čunát pointed out that nix-env would
>> > currently force a download at evaluation time as a result of that
>> > change, and that's undesirable.
>> >
>> > I see it as inevitable that we'll have to start importing from
>> > derivations to make external package ecosystems more manageable.
>> > Currently, haskellPackages is already eating up a large chunk of the
>> > overall repository size, and as we start adopting similar automated
>> > processes to manage other ecosystems, I see no way to keep the repo
>> > size manageable. It also feels like a bit of an abuse of a VCS to be
>> > putting autogenerated files in it, as we do today. Especially when
>> > nix
>> > is generally so good at doing that sort of thing for us.
>> >
>> > It seems like the main obstacle standing in the way of this pattern
>> > is nix-env, given its habit (also unsustainable) of forcing the
>> > evaluation of a large chunk of the packages expression. People have
>> > expressed a desire to deprecate that sort of functionality, but I
>> > don't know what sort of timeline such a change could be made on, so
>> > I'm looking for ways to make it more manageable in the meantime.
>> >
>> > Does anyone have ideas on how to improve this? Or am I wrong about
>> > things getting out of control if we don't? Are there other options?
>> >
>> > Thanks,
>> > Dan
>> >
>> >
>> >
>> > Links:
>> > ------
>> > [1]
>> > https://github.com/NixOS/nixpkgs/pull/11319#issuecomment-167144900
>> >
>> > _______________________________________________
>> > 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
>>
>
>
> _______________________________________________
> 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/20160106/696168fe/attachment.html