[Nix-dev] Discussion: env vars as glue

[phreedom at yandex.ru]

On Понедельник 15 апреля 2013 23:43:59 Lluís Batlle i Rossell wrote:
> 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?
Yes. Think of it as opportunistic mostly trouble-free glue(shared daemons and 
databases are pretty much impossible to fix with the resources we have 
regardless of approach taken).

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

You might be right that the current real-world usage stats are skewed like 
this, so on average this might cause less grief, but doesn't really solve the 
problem.

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

Because you don't know how to do it properly(like 99% of others). I agree that 
it's too much hassle and definitely should be simplified: wrappers, nix-env 
support of propagated-something. There's a real-world demand for a solution.

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

Not only you. nix-env is a much more blunt tool than nixos AND it is supposed 
to handle a more tricky use case :(

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