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

[Evgeny Egorochkin]

On Saturday 08 January 2011 21:14:33 7c6f434c at mail.ru wrote:
> >> 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.
> 
> My point is: unless you also pass checksum or complete checkout, the build
> will fail in chroot build (chroot build is network-isolated on purpose).
> 
> So you only save passing the branch in the most straightforward case.

Not sure what this means, but I guess(hope) it's not too important.

> >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.
> 
> You may have a separate attribute to keep the branch that you follow, and
> then generate full overriding src expressions. It is quite easy, to be
> honest.
> 
> >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.
> 
> Just write a "method" attribute and use it to select a script.

This is exactly what I had in mind.

> Do not
> overgeneralize any more than putting one explicit extension point for now.
> 
> >> 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.
> 
> I think that just explicit src argument and nothing else in the arguments
> (and some meta or passthru attributes for detailed information) is enough.

But where would the values of those meta/passthru args come from?

> To get comments on that small detail, you are better off asking explicitly
> about it. Never rely on commit replies - there can be none.
> 
> >> >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?
> 
> Frankly, given that we already have all-packages.nix walking code for
> release.nix, the only question here is whether meta or passthru is better
> here. Maybe it should be a generic update automation solution, though.
Indeed it may be a good idea to generalize it further. Thanks for the pointer 
to the walking code --  I was looking for it :)

> Please take a look at pkgs/build-support/upstream-updater/ - it has a big
> drawback of requiring 3 files per expression, but it is a working solution
> for updating both tarball versions and fetchscm revisions to the latest
> available. It does some things quite badly (it requires specifying data in
> a way that is tied to specific implementation), but you can see whether it
> does some things right.
> 
> I guess you could have a script that does release.nix-like walk of all
> packages, find every package with meta.updateInfo.method defined, call
> corresponding script to create new src expression and then (by user's
> choice) update package src definition (I prefer to create a srcInfo with
> some extra data like version and then just inherit needed attributes as
> fetchsomething parameters; maybe marking srcInfo attrSet with
> autoUpdatable = true; is a good way to mark this place for scripts?),
> update user's personal override set (import'ed by config.nix) or discard
> new knowledge.

This is close to what I had in mind, although I planned to get away without 
making lots of files. 

-- 
Evgeny