[Nix-dev] [***SPAM***] Re: Improving the Developer Experience in the Nix Community

[Michael Raskin]

>> Frankly, from the technical point of view I would prefer a set of 
>> overridable knobs gradually added to the packages in the main set. This
>> gives easier discoverability which is nice. Of course, this clashes with
>> the struggle for simplicity of the main expression or something else 
>> like that. 
>Ah, ok. I think if we were to do this documentation would be essential: what does this knob do, how does it do it, how might it break if something were changed elsewhere, when would a user consider using it, etc. But it's a good idea (also another place for values to clash :))

Well, so far I am interested in the knobs usable by someone who knows
what in the build process needs to be changed but wants to save time on
debugging the build per se. It can be useful for people who write nix
expressions fluently even before documentation; the most used options 
would deserve a comment, probably - maybe added as an expression of 
gratitude by some later user.

>> It is better than it was a couple years ago. But still, it is way less 
>> than what I would like to use. How do I split preConfigure into a part 
>> setting a few variables and a part editing an .inc file so that it is 
>> easy to insert code between them?
>> 
>
>Use nix's highly expressive string primitives ;).

Which are somewhat lacking.

>In seriousness, I see what you mean. Does builderDefs solve that issue? How?

builderDefs solve this specific issue by allowing you to specify a list
of build phases not constrained by any unincreasable set. The drawback
is that you always need to specify the list of build phases.

>>>> - There is a way to add support for marginal improvements to the default
>>>> builder without full rebuild (why would we want to need stdenv-updates
>>>> just to add xz support?)
>>> Agreed. Would you be interested in collaborating on a modular-stdenv (or something similar) branch to make this a reality?
>> I want someone else to make the basic design plan. It is obvious that
>> whatever I propose here will be too similar to builderDefs (with all its
>> problems) to be accepted. I have this experience, and am ready to help 
>> to anyone who prepares a better design.
>Ok. Why was builderDefs rejected? What problems do you see with it, and what do others see?

As I understand, the problem others see is somewhat more detailed (and 
so cumbersome) syntax. I cannot write standard mkDerivation packages out
of my head anyway, so I use template with all the parameters mentioned;
this way it is not important whether I use builderDefs or mkDerivation
proper.

Also, it looks like some people consider post-configurability of 
expressions a drawback, not a feature. And nobody cares about having to
do trivial local changes via stdenv updates and full rebuild.

>Ah, ok, I assumed all of these were things you wanted to change. Yes, definitely having hydra still be useful is a good goal.

The values after these two could be achieved in a not-Hydra-friendly or
a not-rollback-friendly way. I want to disclaim any support for such 
implementations.

>>>> - There is a simple way to declare something an acceptable substitute of
>>>> something else.
>>> Do you mean substitute in the sense nix uses it, i.e. a way to realise a path without building it? Or something else?
>> Yes, this. I mean something that can be specified from command line to
>> nix-store, not by installing more Perl scripts.
>Mm, ok. Did you have an interface in mind?

Not specifically. I think that basically it would explicitly say 
nix-store to consider path A a substitution for path B. After we have
some experience with this feature marked "dangerous", we could go on.

>>>> - There is a simple way to derive a version of package with dependency
>>>> versions changed (for use with subsituters, mainly)
>>> Can you expand on this here? How would such a feature help?
>> 
>> I claim (as system administrator) that glibc 2.x.y is a drop-in 
>> replacement for 2.x.y-1, and I would like to test this. If I am OK
>> with the results, I do a pseudo-rebuild to close the security hole and
>> clean up later.
>Now that's a complicated but potentially very useful feature. Have you looked into hash-rewriting as a possible solution? You wouldn't even have to break any nix invariants this way.
>
>Maybe I'll look into writing a 'replaceDependencyWithoutRebuild' function.

I haven't yet explored ways to implement such functionality. Given that
a much simpler absolutely invariant-obiding utility scripts was called
suspicious (nix-reduce-build), I want to find out whether there is any 
chance to have it in mainstream Nix first.