[Nix-dev] Discussion: env vars as glue

[phreedom at yandex.ru]

On Понедельник 15 апреля 2013 23:04:34 Lluís Batlle i Rossell wrote:
> 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.

And framework isolation would at least ensure no crashes happen if the user 
forgets that he's the one doing the glue.

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

After things crash, yes. That's the status quo.

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

There are many useful cases especially if you know the limitations: cli tools 
almost never fail, "peek" install of pretty much any app(even if it breaks 
later).

I see that the wrapper solution isn't bad, but requires a lot of manual work. 
Also, framework isolation and wrappers don't really conflict, in the sense that 
wrappers can be implemented on top of isolation or isolation can be seamlessly 
added later. Wrappers or an equivalent are still necessary to make it easy to 
install kde apps on non-nixos or non-kde desktop.

Do you have an implementation proposal for a wrapper. I imagine you'd have to 
make a bunch of high-priority packages like wrappedGSTApp = gst_wrapper { 
originalGSTApp, GST_plugin_config }; and gst_wrapper would steal name, version, 
symlink everything but binaries, wrap binaries... quite a job