[Nix-dev] "live builds" proposal

[Evgeny Egorochkin]

On Sunday 01 August 2010 14:12:05 Marc Weber wrote:
> Excerpts from Yury G. Kudryashov's message of Sun Aug 01 01:20:28 +0200 
2010:
> > Hi!
> > 
> > I propose the following extension to the nix language that will allow
> > native support for "live scm builds" etc.
> > 
> > If nix is called with --enable-exec, the new function builtins.exec is
> > added. The proposed syntax is like the following:
> > 
> > src =
> > 
> >   if builtins ? exec then
> >   
> >     # fetch to ~/.nix-checkouts/name
> >     builtins.exec [ "nix-prefetch-svn" .... ];
> >     builtins.filterSource "~/.nix-checkouts/name"
> >   
> >   else if pathExists "~/.nix-checkouts/name" then
> >   
> >     builtins.filterSource ...
> >   
> >   else
> >   
> >     fetchsvn { # url and hash for some specific revision
> >     };
> > 
> > Of course, all this logic should be hidden in new fetchsvn/fetchgit etc.
> > functions.
> > 
> > The main drawback of this solution is that the result of a nix expression
> > will depend on some things outside of the nix expression. That's why I
> > propose to enable this builtin only if nix is called with --enable-exec:
> > if you want to rebuild your system from the configuration written a year
> > ago, just do not add --enable-exec.
> 
> I think its worth talking about this because most of us want this in
> some or another way.
> 
> Yury: Think about having two repos:
> 
> nixpkgs-checkout-A
> nixpkgs-checkout-B
> 
> nix-env --exec -f nixpkgs-chekcout-A -q \* # will this checkout / update
> everything?
> 
> Should this have an effect at
> 
> nix-env --exec -f nixpkgs-chekcout-B -i INSTALL_SOMETHING
> 
> ?
> 
> The issue is that your state is located in ~/.nix-checkouts.
> 
> My state is located in the .nix file. Each time I run
> nix-repository-manager . --update NAME the .nix file is changed telling
> it exactly which snapshot to use.
> 
> So working on repo A never affects repo B.
> 
> I dislike this kind of impurity that repo-A affects repo-B. So I will
> always prefer my solution for that reason.
> 
> How do you think about this? do you want to rm -fr ~/.nix-checkouts in
> order to reproduce some compilations ?
> Do you use a different system account on your machine then?
> 
> I'm willing to support a nixier solution. But I dislike this particular
> design decision. Can you comment whether you were aware of it and how
> you feel about it?
> 
> Can you think about how a DSL could look like? Something like this?
> 
>   src = upstream {
>     type = "svn";
>     svnUrl = "...";
>     lastRevKnownToWork =  724;
>   }
> 
> Its paying of thinking about it soon.
> 
> I'm willing to help finding a nixier solution if benefits / amount of
> work ratio pays off.

How about
{..., fetchfunc, repo ? "git:/...", rev ? "56789"}:
...
  src= fetchfunc {
    url = repo;
    inherit rev;
  }
...

Thus you can easily override revision and repository eg point to your own 
(local) branch.

This leaves it up to maintainers to periodically bump rev. Although if you 
want *working* live builds, it means that you need to at least override and 
test if it compiles(maybe even works?) before bumping so at first there will be 
no way around doing some manual work.

Of course this probably can be automated with a script or two...

P.S. 2c from a nix noob :)

-- 
Evgeny