[Nix-dev] Dataflow

[Malcolm Matalka]

It's unclear to me what problem your proposal solves.  If the source of
the issue is the package itself is paralleizing builds (i.e. rebar) then
how does making Nix more dataflow solve that?

stewart mackenzie <setori88 at gmail.com> writes:

>> Maybe I'm wrong, but I don't think the Nix language itself has any idea
>> of concurrency as such -- at the manual says
>>
>>    "The Nix expression language is a pure, lazy, functional language."
>>
>> (https://nixos.org/nix/manual/#ch-expression-language)
>
> Actually I recall eelco talking about threads in nix. IIRC there was a
> motion to remove them but he wanted to keep them.
>
>> Therefore, there's no value in adding concurrency unless your bottleneck
>> is the actual derivation of the build *plan* (not the actual build).
>
> You're quite correct, indeed I was referring to the build plan. One
> light weight language thread calling the build tool for each
> build/package that forms part of the build plan.
> If one uses declarative concurrency I suspect one could essentially
> remove much of the build plan logic that's in nix-the-language.
>
> I need to do some more reading.
>
>> As you've discovered, your problem is that the underlying mechansism is
>> impure (and buggy). There's nothing Nix-the-language can do about that
>> -- unless you want to go about replacing the build systems used by
>> individual programs by more principled ones. I'm sure we'd all love
>> that, but it's not a trivial task and need buy-in from any potential
>> upstream.
>
> Well that's certainly not going to happen any time soon. :) It was
> just rather annoying trying to debug something that keeps hopping
> about.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev