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

[7c6f434c at mail.ru]

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

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

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.

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.