[Nix-dev] Discussion: env vars as glue

[Lluís Batlle i Rossell]

On Mon, Apr 15, 2013 at 11:47:00PM +0300, phreedom at yandex.ru wrote:
> On Понедельник 15 апреля 2013 22:11:17 Lluís Batlle i Rossell wrote:
> > 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.

Hm I wouldn't think a nix user (not nixos) would use nix that way. But who
knows. In any case, on non-nixos those variables won't be set.

And if you mean nixos, for such user maybe the gst plugins are already in the
GST_PLUGIN_DIRS variable (system path).

If the user ends up installing ffmpeg gst plugin and the app, that will require
a careful updates, because *he* is doing the glue between libraries; the update
of one won't trigger the update of the other.

> 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.

Maybe that user will think that he has an old nixos system profile, too.

> 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 :(

I mean that it should not be so much up to the user, and that's what nix-env
ends up doing, specially when those variables point to the user profiles.
nix-env works great to install programs, but I don't think it fits the task for
installing pieces that interoperate with a specific API (match or crash).
Becausae update of one won't trigger the update of the other, and even less when
the glue happens through different profiles (system vs user, user vs root, ...)

> 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...

I still think it's better to handle that in a more nixy way, making users set up
~/.nixpkgs/config.nix tuning wrappers, if required. That will have a somewhat
stepper learning curve for those wanting the use cases you posted above, but
those use cases are already of quite advanced users. The wrappers could even be
set to enable most plugins, and advanced users would disable them at will.

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). :)

Regards,
Lluís.