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

[Evgeny Egorochkin]

On Thursday 06 January 2011 23:19:04 7c6f434c at mail.ru wrote:
> >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.

I did overlook this. Of course overriding src via an argument is slightly 
easier than overrideDerivation, but if documented, it's ok. Yes, I do plan a 
liveBuilds wiki page. So src argument goes away.

Now, as to partially overriding src, it's more than simply about convenience, 
even though pinning a particular revision by hand is much easier this way.

You need this to implement any kind of branch following(the dirty way or via 
an external script) because you need repository, branch and revision 
explicitly stated. Whether it's done via derivation arguments + external 
manifests or src-for-default.nix approach is another matter.

What I have doubts about right now is that the current format is flexible 
enough. RIght now you can't change the repository type and retain this 
explicit representation, even though I suspect this is going to be a very 
common case with git-svn branches of svn repos. Probably, a good solution is 
to write a fetchscm function which would also take a repository type argument 
and use it instead of fetchgit etc, same goes for fetchgitrevision-
>fetchscmrevision.

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

The seemingly small details still matter, because I'm trying to figure out a 
good approach, not just make a derivation for a single package.

> >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.

Regarding the manifest-based approach, there are several interesting 
possibilities. What I have a in mind is evaluating all-packages.nix to obtain 
the list of all live builds available and their repository+branch data and 
generating manifest based on this. The question is how to do it the best way? 

Is adding passthru = { livebuild = { rev = "..."; repo = "...";}; }; to 
identify the live build the best way or am I missing something better?

-- 
Evgeny