[Nix-dev] Re: [Nix-commits] SVN commit: nix - 22282 - MarcWeber - nixpkgs/branches/stdenv-updates/pkgs/stdenv/generic

[Marc Weber]

Hi Lluís Batlle,

I'm a little disappointed about that I think that you missed an
important item: There is a *global opt-in*. So I consider the whole
reply you sent (and maybe the whole discussion you've had with Ludo)
pointless unless you confirm that you're aware of that.

To opt-in you have to set MAX_PARALELIZZATION and TARGET_LOAD in either:
nix.conf or the nix-daemon upstart configuration.
Unless you do so nothing changes (except than -j1 may be passed to make
which only causes huge amount of rebuilds. But there is no other way)

> 1. Hydra does not need the in-build parallelization, she has enough with the
> inter-build parallelization
I never asked for switching on this feature for Hydra. I clearly said
so.
By the way: in built parallelization is the *only* way to make Nix*
react faster to security vulnerabilities which may pop up at any given
time. You can ask several Amazon build farms to build at the same time.
But you can no longer speed up single builds unless you opt-in.

So for business and some use cases of Nix this can be critical in the
future.

> 2. There is no way for nix to manage the balance between in-build and
> inter-build parallelization (make -j, and nix max-jobs).
Which means you didn't even try it. It actually works quite fine.
I also clearly said this is a compromise.

> 3. Nix developers, wanting a quick build for testing, can add the "make -j X"
> temporarily before commiting the expression.
I can follow you when thinking about building packages such as OO
only. But there are additional use cases:
If you want to track down an error you have to build more than one package.
Does something still work if I use a different python version
etc. Answers to questions like this will be present much faster when
opting in. For custom kernels and eg ghc this does make a huge
difference.

> 4. The benefits of your change come at the expense of some clarity in stdenv,
> and some impurities, and in the nix world many don't like impurities much.
Which impurities? Again. This all is *opt-in* by default. So no. It does
not add impurities unless you opt-in which I did never expect to happen
on Hydra.

Clarity? Can you be more precise? Which patch makes stdenv that much
less readable? And how would you implement this feature?
Doesn't removing duplication improve clarity?
I'd like to improve for future commits.
But well. I guess you've read this request in my last mail that Ludo
should show me a different implementation so that I can learn how
"clear" code looks like.

Ludo, Lluís Batlle: Just saying "this is bad style', revert?
Is not enough. I'd like to ask you both in the future to give
alternatives instead. Just saying no is bad and doesn't help much.

> 5. By default, generic builder expressions should not be built parallelizing at
> all.
Yes. That's why they don't unless you globally *opt-in*.

> I'm for the revert, considering what I wrote above. I prefer a

Lluís Batlle: I don't know whether you have read what I wrote. They way you
argued without showing that you are aware of the global opt-in makes me
wonder whether you've understand the whole patch.

So confirm that you were aware about the global mandatory opt-in and
I'll revert although I want this patch. I don't want to cause trouble to
majority. Me reverting this patch could lead to a fork. That's what open
source is about.

Remembering your recent statement
22:07 < Lluís Batlle> It's incredible how I pay more attention to irc
than to nix-dev ;)

I'd like to ask you to pay more attention to commit messages (thus the
list) If my descriptions were unclear help me to improve them, please.
They said multiple times that everything defaults to 1.

I'd like to be part of this Nix* team. But you have to help me having
fun being one. I can't do better because I do not know what "better"
means. Help me, please.

Marc Weber