[Nix-dev] Moving some of the NixOS setup to nixpkgs

[Florian Friesdorf]

On Fri, Oct 03 2014, Shea Levy wrote:
> Hey all,
>
> I've only briefly browsed through the thread, so maybe this is
> repetitive, but I think whatever we do here we should separate out the
> "raw" package from the tool that configures the environment for it, so
> that the package can be composed in different ways without the overhead
> of the wrapper or symlink tree or whatever.

I consider this especially true for packages where you need to recompile
just to change the wrapper. If it is not a build-time dependency of a
package it should not be a buildInput. But instead, like I understand
Shea, there should be a raw package and packages that use the raw
package wrapped in different ways.

While we are on it, we could have the compiled build dir as an output,
which is then used by the install/fixup phases.

There could be an additional wrapPhase with a sane default wrapping
which one can override. The wrapPhase would create an output that
contains references to the install/fixupPhase output, using it as
runtime dependency. The compilation output would be discarded by garbage
collection except if some flag/config option is set.

Florian

> On Wed, Oct 01, 2014 at 11:11:38AM +0200, Wout Mertens wrote:
>> Hi all,
>> 
>> TL;DR: I'd like to discuss the empty space between declarative NixOS
>> systems and imperative nix-env user profiles.
>> 
>> 
>> As we all know, nixpkgs provides compiled packages and NixOS ties them
>> together with environment variables, configuration files and systemd
>> services.
>> 
>> This dichotomy causes a bit of a problem for user environments, especially
>> on nixpkgs installs outside NixOS.
>> 
>> Examples are the environment variables TZDIR, CURL_CA_BUNDLE,
>> OPENSSL_X509_CERT_FILE and others, which are in place for NixOS users but
>> not for nixpkgs users. Without these, glibc and curl don't work 100% right.
>> Plain nixpkgs installs should have these set in the user environment
>> somehow.
>> 
>> Another issue, is that configuration files are only generated for NixOS
>> services. So if you as a user want to use nginx on an unprivileged port for
>> development, you need to generate the configuration by hand instead of just
>> specifying a port and getting a wrapper.
>> 
>> One more related topic is declarative user environments. You can do it [1],
>> but it's a bit of a hidden feature and not very straightforward.
>> 
>> So I'm hoping that we can come up with a system where:
>> 
>>    - configuration wrappers are in nixpkgs, and NixOS modules use those.
>>    - multiple configurations of a package become multiple wrappers with
>>    user-definable names
>>    - environment variables like TERMINFO are declared in nixpkgs instead of
>>    NixOS modules and synthesized into the user environment instead of via NixOS
>>    - declarative user environments are made as easy as possible. Perhaps it
>>    should be the default and nix-env only edits the declaration.
>> 
>> Thoughts please!
>> 
>> Wout.
>> 
>> [1]:
>> https://nixos.org/wiki/Howto_develop_software_on_nixos#Obtaining_an_Environment_from_a_Custom_Definition
>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

-- 
Florian Friesdorf <flo at chaoflow.net>
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20141003/70ded2d9/attachment.bin