unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, 53447@debbugs.gnu.org
Subject: [bug#53447] Introducing ‘GUIX_’-prefixed environment variables
Date: Wed, 26 Jan 2022 23:53:02 -0500	[thread overview]
Message-ID: <87k0el230x.fsf@gmail.com> (raw)
In-Reply-To: <f03155b599c48a4a46e667df7aa104c6da678e6e.camel@gmail.com> (Liliana Marie Prikler's message of "Wed, 26 Jan 2022 21:03:05 +0100")

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	other threads:[~2022-01-27  4:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-22 14:13 [bug#53447] [PATCH] doc: Unset environment variables considered harmful Liliana Marie Prikler
2022-01-22 16:04 ` Ludovic Courtès
2022-01-22 17:53   ` Liliana Marie Prikler
2022-01-24 22:27     ` Maxim Cournoyer
2022-01-25 13:29       ` [bug#53447] Introducing ‘GUIX_’-prefixed environment variables Ludovic Courtès
2022-01-26  1:56         ` Maxim Cournoyer
2022-01-26 12:05           ` Ludovic Courtès
2022-01-26 20:03             ` Liliana Marie Prikler
2022-01-27  4:53               ` Maxim Cournoyer [this message]
2022-01-25  7:39     ` [bug#53447] [PATCH] doc: Unset environment variables considered harmful Ludovic Courtès
2022-01-25 19:21       ` Liliana Marie Prikler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0el230x.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=53447@debbugs.gnu.org \
    --cc=liliana.prikler@gmail.com \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).