[Nix-dev] Re: [Nix-commits] SVN commit: nix - r25375 - in

[7c6f434c at mail.ru]

>I don't propose we adopt my solution widely. In fact, downloading a tarball is 

Well, such things do like to creep.

>so much better and faster. I propose to adopt it only where other solutions 
>fail or are inferior.
>
>Now, the solution itself ctually consists of several losely-related parts.

Of course; and my opinions on these parts differ.

>One part is essentially a scm build approach which makes it easier to override 
>the source and which abstracts away the potentially dirty code that decides 
>which revision is getting built.

1) Simply overriding src attribute works OK; of course, sometimes overriding it
only partially is nice.

2) I am in favour of including fetchscm expressions where applicable and I do
maintain a few fetchscm-only expressions. 

3) My main point is that any Nixpkgs-trunk code for deciding which revision 
gets built should better be deterministic and chroot-build friendly.

So, what is the simplification in overriding? That you explicitly list src
as an argument with a default? Sometimes nice. Keep in mind that with 
default builder there is overrideDerivation and builderDefs support simply
passing new src.

>Another part is one of the possible implementations of the revision decision 
>function, and the dirtiest of the possible implementations. I agree with the 
>criticism that it fails at reproducibility department making bisecting system 
>configs a problem.
>
>What bothers me is that  ALL criticism and discussion so far was centered 
>aroung this small bit of code(calling it the solution btw), ignoring the 
>proposed scm build format and the fact that the revision logic is pluggable.

Let me explain my (incorrect) perception of the style change that still 
guides my reactions.

We have a few style changes about overriding (nearly trivial w.r.t. 
functionality gained), some pluggability of logic (not clear if any of 
implementations beyond what we already had can work nicely with nix-env -q 
and chroot builds) and an implementation with a few clever tricks (I never 
thought all that could work anyhow) but with a few significant drawbacks.

Guess what gets commented on - the trivial part, or whether piece-of-art
code can be moved into "science" area?

>What I DO agree with is that the dirtiest fetchgitrevision approach should not 
>be made the default, it was a mistake on my part.
>
>I see the dirty revision approach as an easy way to run a trunk build of some 
>program by the end user, not necessarily the best and only approach, such as: 
>try a dirty live build, if it works, pin the revision which is has just 
>printed in console and forget about it; or as in case with redmine, follow the 
>maintenance branch.

What really bothers me is what can be left of all that glory that doesn't
conflict with dry-runs, no-build instantiations and chroot builds. 

>The manifest-based approach is what you would use if you used many live 
>builds, or wanted to bisect the config. And I do plan implementing this as 
>well. This entails having a manifest file put under revision control and an 
>external script to fetch current revisions.

If I use few live builds, I just keep checkouts. If I want many live builds,
I somehow generate a manifest (actually, I mentioned manifests as an example
of an action which is not really a build but is done by nixos-rebuild). 

It is very likely that the latter (maybe even the former) can benefit from 
adding your ideas.