[bug#61982] [PATCH 2/2] home: services: xdg-base-directories: Deprecate XDG_LOG_HOME.

[Philip McGrath]

Hi,

On Thu, Jun 15, 2023, at 11:28 PM, Andrew Tropin wrote:
> On 2023-06-15 14:09, Philip McGrath wrote:
>
>> Hi,
>>
>> On Thu, Jun 15, 2023, at 5:35 AM, Andrew Tropin wrote:
>>>
>>> WDYT about adding (home-log-dir) function to (guix build utils)?
>>> So we can prevent copypasting the same code all over home modules.
>>>
>>> Something like:
>>> --8<---------------cut here---------------start------------->8---
>>> (define (home-log-dir)
>>>   "Returns a directory for user applications logs."
>>>   (string-append
>>>    (or (getenv "XDG_STATE_HOME")
>>>        (format #f "~a/.local/state"
>>>                (getenv "HOME")))
>>>    "/log"))
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>
>> I still think idiomatic XDG structure is NOT to have a "/log"
>> subdirectory like this, as I explained in
>> <https://issues.guix.gnu.org/61982#7>.
>
> With a brief look I didn't find information about this idiom in
> specification, but you can highlight it with quote or link.
>
> Anyway, I'm ok with storing logs in app subdirectory or "/log", not so
> ok with storing them in the root of state home.
>

You are right that the idiomatic usage isn't made very explicit in the 
specification. In the specification itself, the idiom is implicit in the 
"Referencing this specification" section, which always uses a subdirectory:

>
> Other specifications may reference this specification by specifying the 
> location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies that:
>
> - Such file should be installed to $datadir/subdir/filename with $datadir 
> defaulting to /usr/share.
>
> - A user-specific version of the data file may be created in 
> $XDG_DATA_HOME/subdir/filename, taking into account the default value for 
> $XDG_DATA_HOME if $XDG_DATA_HOME is not set.
>
> - Lookups of the data file should search for ./subdir/filename relative to 
> all base directories specified by $XDG_DATA_HOME and $XDG_DATA_DIRS . If an 
> environment variable is either not set or empty, its default value as defined 
> by this specification should be used instead. 
>
> Specifications may reference this specification by specifying the location of 
> a configuration file as $XDG_CONFIG_DIRS/subdir/filename. This implies that:
>
> - Default configuration files should be installed to 
> $sysconfdir/xdg/subdir/filename with $sysconfdir defaulting to /etc.
>
> - A user-specific version of the configuration file may be created in 
> $XDG_CONFIG_HOME/subdir/filename, taking into account the default value for 
> $XDG_CONFIG_HOME if $XDG_CONFIG_HOME is not set.
>
> - Lookups of the configuration file should search for ./subdir/filename 
> relative to all base directories indicated by $XDG_CONFIG_HOME and 
> $XDG_CONFIG_DIRS . If an environment variable is either not set or empty, its 
> default value as defined by this specification should be used instead. 
>

(Obviously $HOME/.local/bin is a special case, since using subdirectories there 
would defeat the point.)

More than the text of the specification, I'd look at actual observed usage and 
documented best practices. The relevant Gnome Goal [1] (despite outbound 
linkrot) is consistent with every other developer guide I've seen in showing 
the use of subdirectories, e.g. in the Glib example code:

```
const char *cache_dir = g_get_user_cache_dir ();
char *mydir = g_build_filename (cache_dir, "myapp", NULL);
/* use it */
g_free (mydir);
```

(Glib now provides g_get_user_state_dir, too. [2])

The Arch wiki has a survey of XDG support status [3] that consistently shows 
applications using appropriate subdirectories.

[1]: https://wiki.gnome.org/Initiatives/GnomeGoals/XDGConfigFolders
[2]: https://docs.gtk.org/glib/func.get_user_state_dir.html
[3]: https://wiki.archlinux.org/title/XDG_Base_Directory

>>
>> Aside from that, though, I thought the conclusion from
>> <https://issues.guix.gnu.org/56050#3> was that it is the
>> responsibility of Guix System or the installation mechanism for Guix
>> on a foreign distribution (e.g. "/etc/profile.d/zzz-guix.sh") to
>> initialize all of the XDG variables, so code like this can use
>> `(getenv "XDG_STATE_HOME")` unconditionally (or indeed with a checked
>> assertion). Maybe there's some context I'm forgetting, though. I've
>> been looking into these things again as I attempt to solve
>> <https://lists.gnu.org/archive/html/help-guix/2023-06/msg00031.html>:
>> I noticed in the attached environment variables that entries under
>> /home/philip/.guix-home/profile/ are duplicated in many search paths.
>
> home-state-dir function can also be useful, which can later become just
> (getenv ("XDG_STATE_HOME")).
>

I'm not at all opposed to providing functions rather that using getenv 
everywhere: they could guard against typos, check invariants, and all the other 
usual helpful things. But---though maybe I'm missing some context---how often 
is it actually needed to pass these default values? As long as the upstream 
software supports XDG directories properly, I would think it should just do the 
right thing without having to pass a bunch of explicit configuration options.

-Philip