[Nix-dev] some questions

[Erick Tryzelaar]

Hello Eelco,

Thanks for the response! Here's some follow up:

Eelco Dolstra wrote:
> Yes, you can use the -f flag to use all-packages.nix, which provides all
> packages, not just the ones pre-built for the channel:
>
> $ nix-env -f path-to-nixpkgs/pkgs/top-level/all-packages.nix -i pkgname...
>
> We've thought about getting rid of build-for-release.nix (at least, not making
> that the top-level expression for the Nixpkgs channel) to make it easier to
> allow people to use the non-prebuilt packages.  Maybe with a flag to hide/show
> those packages.

That would be handy, especially since for the install version the path 
to nixpkgs is something like:

/nix/store/0hr9wrwhiq18l3gils4s0vzhi9rkb795-channels/1

And it's a pain to track down which directory goes with which channel.


>> Or even better,
>> type/namespace/project-version/guid, where type is
>> user-environment/channel/downloads/etc and namespace is the java-like
>> nix.cs.uu.nl? It's a little hard to navigate this way.
>
> This would be bad, because then you don't have sharing between user
> environments.  I.e. if two users install the same package, it shouldn't be
> stored twice.  Likewise for the channel: different channels can provide the same
> store paths.  Example: the Nixpkgs channel and the Stratego/XT channel provide
> exactly the same Glibc.

Good point. What about another profile-like system for this? This would 
let you have:

/nix/ns/nix/channels/nix-unstable     -> /nix/store/0hr...-channels/1
/nix/ns/nix/channels/nixpkgs-unstable -> /nix/store/0hr...-channels/0
/nix/nx/nix/nixpkgs/zlib/1.2.3 -> /nix/store/zld...-zlib-1.2.3
/nix/nx/nix/drv/apr-util/1.2.7 -> /nix/store/zqz...-apr-util-1.2.7.drv

This would let you easily browse the directory structure while still 
letting you share binaries between users.

>> 3. Along these lines, it's a little hard finding the channel files.
>> They're currently something like:
>>
>> /nix/store/0hr9wrwhiq18l3gils4s0vzhi9rkb795-channels/0
>> /nix/store/0hr9wrwhiq18l3gils4s0vzhi9rkb795-channels/1
>>
>> Instead of 0 and 1, it would be nice if they could also follow a
>> namespace/project-version/guid. So it'd be something like:
>>
>> /nix/store/nix/channels-0hr9wrwhiq18l3gils4s0vzhi9rkb795/nix.cs.uu.nl/nixpkgs-unstable
>>
>> /nix/store/nix/channels-0hr9wrwhiq18l3gils4s0vzhi9rkb795/nix.cs.uu.nl/nix-unstable
>
> Hm, that's a pretty good idea :-)  I haven't needed something like that myself
> because I just have a Subversion checkout, but that's not true for users in
> general, of course.  I'll make an issue about it.

I don't think this has made it yet into jira. Want me to add it for you?

>> 4. From what I can tell from the documentation, it's possible to compile
>> code while enabling different features, such as one build of subversion
>> supporting mod_dav_svn, and another not. But I can't figure out how I'm
>> supposed to do this. macports, another packaging system for the mac, has
>> something similar called variants, where you just do this:
>>
>> port install +mod_dav_svn
>>
>> Which adds a dependency on apache2, and appends
>> "--with-apxs=${prefix}/apache2/bin/apxs --disable-mod-activation" to the
>> configure. It works out well, but the downside is that one package can't
>> depend on another package's variants. I believe nix can do this. Is
>> there a simple interface for it?
>
> Not really a *simple* interface, but Nix expressions being a purely functional
> language, it is certainly possible.  It's just that all-packages.nix isn't very
> flexible: it calls the functions that build the various packages with mostly
> fixed arguments.  You can of course make your own function that calls them with
> different arguments.  For instance, all-packages.nix builds Subversion like this:

Thats pretty cool! Not that user friendly though.

>> 5. rpm and apt have a nice feature where one .spec file can generate
>> multiple packages. This lets you split up bundling development files and
>> libraries. Can nix do this?
>
> No, not yet, but it's been a long-time to-do item.  The problem is that it's not
> quite trivial.  If a derivation has multiple outputs in the Nix store, then
> presumably those outputs can be downloaded *and* garbage-collected separately
> (otherwise there would be no point).  But if output A is garbage-collected and
> output B is still in the Nix store, and you then need A, you would have to
> rebuild, but this would overwrite B, leaving the system temporarily in an
> inconsistent state.  (Since there might be other packages referring to B.)  I do
> have a rough idea of how to fix this, though.

What about one src package generating multiple binary target packages? 
In rpm, after A and B are generated from S, I believe they're 
independent of each other, as long as there aren't any specified 
dependencies. So we'd add A and B to nixpkgs, and then the act of adding 
and removing A or B shouldn't effect the other package. The only time 
you'd have a conflict is if you try to install S, but all it'd over 
write is the package B, not the install file.

>> 6. I read that I can either build a package, or install a prebuilt one.
>> How can I select between the two?
>
> You can't - if you've nix-pulled, then Nix will download a pre-built binary if
> it's available.  If you really do want to build from source in that case, you
> can do "nix-store --clear-substitutes" to get rid of the nix-pull registrations.
>

Does this permanently clear the cache?