[Nix-dev] Discussion: env vars as glue

[Lluís Batlle i Rossell]

On Tue, Apr 16, 2013 at 12:33:37AM +0300, phreedom at yandex.ru wrote:
> 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.

What do you mean by 'framework isolation'? Is it some feature we don't have but
can have?

I think that the user shouldn't be doing any glue without doing some effort in
that direction. An effort that would remind him that he is 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.

We have more cases of old software running in a new nixos, than broken
new software in an old nixos. Mainly because the the compatibility usually goes
backwards, not forward, no? :)

Then, I think that we win something, by having the plugin dir vars pointing only
to the system profile.

> > 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 KDE apps on non-nixos work at all? On a nixos non-kde desktop, it works very
bad. And I'd prefer some nixpkgs functions that would allow me to install KDE
things without me making much glue through the installation of multiple pieces
with nix-env.

> 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

Well, I might be not the best person for that. I think I don't use most of those
variables. :)

Maybe, as you proposed, a nixos option could be set to simply divide between the
current behaviour and my view.