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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
