[Nix-dev] Discussion: env vars as glue

[Marc Weber]

Excerpts from Lluís Batlle i Rossell's message of Mon Apr 15 23:04:34 +0200 2013:
> I think that very often people hit those broken ABI issues, the DLL hell,
> thinking that nix-env does more things that joining files in a path with
> symlinks. And I feel that we can't blame the user (as for now). :)

That's what I've been proposing for a long time, eg by writing this
guide:
https://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once

or by using hack-nix or nixpkgs-ruby-env rather then installing
individual plugins.

Gimp is another special case. I've implemented quite a lot of plugins:
https://github.com/MarcWeber/nixpkgs/commit/585b42c8e7c74392bf2825b8d47d46f7db542f1a

and I'm declaring my config.nix installation this way:

packageOverides = p: {
  graphicCollection = misc.collection "my-graphic-tools" [ inkscape (gimp.withPlugins [ "plugin-name-1" "plugin-name2"]) ]
}

Then I update all graphic tools at the same time to make sure they still
build and work.

Gimp is even more awkward: If you edit the global settings (which have
to do at the moment in order to tell it about additional
~/.nix-profile/gimp-VERSION-plugin directories it'll hardcode the plugin
paths in store/hash-gimp-VERSION/ gimp store path, thus after installing
a new gimp, trouble will happen.

So this is another thing which could be fixed in a much better way. The
comments in the commit listed should tell about these details.



Anyway I'd like to draw your attention to my updated version of
multiple-shells-support:
https://github.com/NixOS/nixos/pull/138

It introduces /etc/{bash,zsh}/nix-{bash,zsh}-lib

which makes writing bash/zsh like extensions a lot easier.
Eg it provides 

nix_export_suffix: prefix suffix an env var using separator

nix_foreach_profile: for each profile run a shell command such as nix_add_xml_catalog

nix_add_profile_vars: adds all important paths found in a profile path
to the env vars, such as PERL5LIB, ALSA_PLUGIN_DIRS, GST_PLUGIN_PATH
etc. Basically this is what master does, but its called for each profile
to be added once.

Additionally you can create modular pieces users can opt-out from:

      # could be in configuration.nix:
      # Only makes sense if you also add catalogs to your system profile
      bash/zsh.features.xmlCatalogFileSupport = {
        env_code = ''
          source ${nixZshLibPath}
          # not sure how well this scales - this maybe refactored in the future
          # alternative would be introducing /etc/xml/catalog which might be more impure
          nix_foreach_profile nix_add_xml_catalog
        '';
        lib = ''
          nix_add_xml_catalog(){
            # $1 = profile
            for kind in dtd xsl; do
              if [ -d $1/xml/$kind ]; then
                for j in $(find $1/xml/$kind -name catalog.xml); do
                  nix_export_suffix XML_CATALOG_FILES "$j" ' '
                done
              fi
            done
          }
        '';
      };

If they declared

DID_NIX_ENV_xmlCatalogFileSupport=1

before sourcing /etc/bash/setup-all XML_CATALOG_FILES would not be
defined at all.


One reasen why Lluís Batlle may have started talking about this issue is
the ati_unfree implementation:
If you start blender you'll get a message, that libXext is not found.
If you try adding it to /run/opengl-driver/lib older installations such
as openoffice (which I still had in my profile) stop working.

I'm still wondering which is the best way to fix this:
- adding libXext to rpath of those applications which require
  it such as blender. (This might also fail trying to run older blender
  using newer system opengl environment)
- provide an "ati" run script: $ati blender
  which set LD_LIBRARAY_PATH ?
- add it to /run/opengl-driver/lib and accept that older openoffice does
  not start amyore (even though it does not require 3d rendering at all)

Maybe I should spend more time and find out why opengl or ati drivers
require libXext whereas nvidia does not.

Somehow this also reminds me of the "principle of least priviledge".
Assuming you can't trust any application you should sandbox each
application (eg use a virtual machine for firefox, a different one for
you chat client, a different one for your email client, ...)

You'll get a lot of "safety" - but you'll loose productivity.

Given the problems which will occur such as
- old kde/gnome app will not run in new kde/gnome environmernt
- ...

Eg about X there might be 3 features you're interested in:
- suspend to disk
- 3d acceleration (opengl)
- use external monitors

Now it may happen (for whatever reason) that not all of those features
are provided by all implementations (radeon, ati_unfree)

We will always run into this kind of trouble.

In fact having a system profile and a user profile which "get merged"
already might be causing problems.
nixos-rebuild could guarantee that all kde like apps are build using the
same kde libraries. But you loose this property if you start using a
user profile.

In fact making nixpkgs check some properties, such that two libraries
making up an application are built using the same glib library do make
sense.

I somehow feel that the overall issue is too complex to be solved
easily using the one true way. I personally feel the most efficient way is
to think about what must be done to make something work - and in my case
its just waiting for current libreoffice to be build - or use binaries
using master branch..

Marc Weber