guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#53447] Introducing ‘GUIX_’-prefixed environment variables


From: Maxim Cournoyer
Subject: [bug#53447] Introducing ‘GUIX_’-prefixed environment variables
Date: Wed, 26 Jan 2022 23:53:02 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Hi,
>
> Am Mittwoch, dem 26.01.2022 um 13:05 +0100 schrieb Ludovic Courtès:
>> > Are there any more specific environment variables that exist that can
>> > replace XDG_DATA_DIRS?  I'm not too knowledgeable about the
>> > freedesktop specs, but I'm somewhat skeptical?  If they don't yet
>> > exist, that makes this idea much less actionable.
>> 
>> I don’t know.  Like I wrote, the two main cases are glib and qt.  Why
>> do we have them use XDG_DATA_DIRS for?  This is what we need to
>> investigate.
> Applications based on GLib or Qt usually put their configuration in
> XDG_CONFIG_HOME/XDG_CONFIG_DIRS and their data into
> XDG_DATA_HOME/XDG_DATA_DIRS.  Yes, it's that broad, XDG wants it to be
> that way :P
> There are additional environment variables for some things – one
> example would be GSETTINGS_SCHEMA_DIR – but many things are simply put
> in those XDG directories.  For example, gio, which is part of GLib,
> uses it to look up MIME stuff [1].  Icons and themes follow a similar
> trend as far as I can see.

This is what I perceive too; XDG variables are broad by design, and
there aren't more finer grain alternatives that currently exist.

The main problem to solve in my opinion is to not break the users
environment on foreign distribution.  Plugins for example probably ought
to be searched by GUIX_ prefixed environment variables rather than their
stock versions, else users may find binary incompatible versions to
crash their host-provided application, for example.

I don't really mind how to solve it, but using a prefix seems a
relatively straight forward, bullet proof way to isolate the host from
potentially undesirable effects of installing Guix components.

Imagine if Guix-provided Emacs was to use GUIX_EMACSLOADPATH instead of
EMACSLOADPATH.  This would have the benefit that users could continue
using their host provided Emacs (without having it see potentially
incompatible byte compiled .elc packages) in parallel to the one
installed with Guix.

Thanks,

Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]