[Nix-dev] Discussion: env vars as glue

[phreedom at yandex.ru]

On Понедельник 15 апреля 2013 22:11:17 Lluís Batlle i Rossell wrote:
> On Mon, Apr 15, 2013 at 11:07:16PM +0300, phreedom at yandex.ru wrote:
> > On Понедельник 15 апреля 2013 21:40:08 Lluís Batlle i Rossell wrote:
> > > On Mon, Apr 15, 2013 at 10:17:23PM +0300, phreedom at yandex.ru wrote:
> > > > On Понедельник 15 апреля 2013 18:59:52 Lluís Batlle i Rossell wrote:
> > > > > What uses do you have for:
> > > > > ALSA_PLUGIN_DIRS
> > > > 
> > > > This is used for LADSPA plugins(various sound processing apps)
> > > > and for input/output plugins(eg by pulseaudio).
> > > 
> > > Ok, now, can we make this a nixos-only option? Containing only a
> > > path
> > > prepared by nixos. People who want LADSPAT plugins, set them up with
> > > nixos.> 
> > ALSA_PLUGIN_DIRS is a nixpkgs patch (at least used to be). So installing
> > plugins via nix for non-nix-installed apps is impossible. Otherwise,
> > it's a quite useful feature to quickly install another sound effect.
> 
> I don't mean removing the patch. I mean it not pointing to user profiles,
> only to the system profile, by default.
> 
> > > > > GST_PLUGIN_PATH
> > > > 
> > > > Gstreamer plugins which do all the work. Apparently these are
> > > > loaded
> > > > dynamically. Typical case: kde app plays media via phonon, which
> > > > uses
> > > > phonon_backend_gstreamer to do the actual processing.
> > > 
> > > Don't people usually set this up in nixos, instead of the user
> > > profiles? What kind of plugins people install with nix-env?
> > 
> > Currently KDE in nixos pulls all available GST plugins. A KDE app
> > installed via nix-env still needs this var to access the plugins.
> 
> As above, it'd be fine for me if the variable didn't include the user
> profiles by default.
> 
> > > > > QTWEBKIT_PLUGIN_PATH
> > > > 
> > > > Apparently, this helps webkit steal mozilla's extensions. 
> > > > Likely any
> > > > kde app which is a browser or can use KParts(such as akregator)
> > > > would
> > > > want this set.
> > > 
> > > Maybe this can be set easily up to work with a wrapper like firefox?
> > > What kind of browsers would use that? If only konqueror, maybe that
> > > can be handled by nixos instead.
> > 
> > konqueror, rekonq, akregator, pretty much everything else which might
> > display a web page in KDE.
> 
> So, can this be set up to point only to the system profile?
> 
> > > > You managed to overlook the innocently-looking KDEDIRS. On a
> > > > typical KDE install this place contains 1k+ libs. Among these
> > > > are KIPI plugins shared by at least gwenview, krita and
> > > > digikam, Kparts plugins which are at least shared by konqueror
> > > > and akregator and are always installed by the app supplying the
> > > > part.... While KDE usually requires ABI compatibility in such
> > > > cases, it doesn't help client apps  compiled against newer
> > > > version.
> > > 
> > > Right, KDEDIRS! :)
> > > 
> > > Don't most KDE programs require being set up by nixos anyway? Or
> > > this
> > > KDEDIRS was an addition towards allowing the install of extra KDE
> > > programs in profiles? This does not help much installing KDE
> > > programs without KDE in NixOS, in any case.
> > 
> > Yes, same as always: a quick install of a missing app, development of an
> > app. KDE setup in nixos consists of setting the vars and installing
> > several core packages. Could be done by hand if necessary. Concurrently
> > running KDE apps linked against substantially different KDE versions
> > may be a bad idea though even if frameworks troubles are sorted out.
> 
> Maybe then a user could at will change those variables, if he is "hacking
> something" (to label that not very supported situation), pointing them into
> his profiles.
> 
> What do you think?

You can easily add a nixos option to toggle system profile only/ all profiles 
for the "framework" vars. But what specific problems does it solve?
Let's take the simplest case: GST. The user installs an app that uses GST  
such as a media player, discovers that the player doesn't play mp3, googles 
the easy solution: install ffmpeg GST plugin, installs it and still nothing 
works. The user has to google again to hopefully find out that the var needs to 
be set.

Another possible breakage: the system runs a somewhat old stable profile. the 
user installs an app compiled against a newer version of GST which has 
extended API.

Unfortunately, the only solution which prevents crashes is identifying 
frameworks and isolating plugins/apps compiled against different versions of 
frameworks. This would at least work where frameworks don't launch daemons. It 
may or may not be possible to fully isolate daemons :(

Also, since framework isolation would sometimes take away useful functionality 
from an existing app(eg system-provided kipi plugins are updated and the 
manually-installed gwenview no longer has scanner support or export to various 
web services), it would probably a good idea to somehow store which nixpkgs 
revision was used when building a given package to be able to check it out and 
restore the lost functionality by manually installing the missing stuff. This 
isn't very nice, but it would at least avoid crashes and cryptic error 
messages, the solution can be made googleable("where did plugins/metadata go?" 
wiki article). The only upside to this is that stuff would go missing only once 
per framework, since the user would install the required deps and experience 
no short-term/mid-term breakage...