RCF: Basedir specification for non-Linux

[piegames]

Hi,

in discussions around applications adopting the basedir specification,
the handling of non-Linux systems (especially Windows and MacOS) is
something that really comes up a lot.

*Technically*, the specification is platform-independent, as it only
depends on the concept of environment variables. However, this is not
an accepted solution, as it is not native to these respective
platforms. Instead, a common solution is to use the specification only
on Linux and the respective native equivalents on other platforms.

Thus, I have the following idea: if we set the default value for
$XDG_DATA_HOME, $XDG_CACHE_HOME and $XDG_CONFIG_HOME to the respective
native equivalents for non-Linux platforms, it would make things easier
to adopt on the application side. I am not sure if this is a breaking
change, as the specification is not really explicit whether it even
applies to other platforms at the moment.

A disadvantage is that – at least on Windows – the destination paths
are not computable anymore, and the Known Folders API needs to be
called in order to get the values.

Let me know what you think about this,

piegames

[Simon McVittie]

Post by piegames
in discussions around applications adopting the basedir specification,
the handling of non-Linux systems (especially Windows and MacOS) is
something that really comes up a lot.

I think the right way to think about this is Windows vs. macOS
vs. "basically Unix", rather than specifically Linux being special.

Implementations of the basedir spec on non-Linux Unix OSs like the BSD
family usually use the basedir spec as-is - there's really no reason why
Linux and, for example, FreeBSD should be different here. They're more
similar than they are different (at least from a user point of view), and
they both use something resembling traditional Unix filesystem layouts
for the OS, so they might as well both use the basedir spec for paths
in the home directory.

Windows is really outside the scope of freedesktop.org because it's
neither Free/Open Source Software nor Unix, and it has its own conventions
for where files go. A large part of the purpose of freedesktop.org is
that it gives open-source OSs our own equivalent of the conventions that
Microsoft sets for Windows developers, so that developers can target
"the Linux platform" or "the Free desktop platforms" and have things
work reasonably consistently - but on Windows we don't need that,
because there's only one Windows, and Microsoft already designed it.

macOS is technically a FreeBSD derivative, but the
traditional/conventional paths are different; it could make sense to
special-case it, like Windows, or it could make sense to just treat it
as just another Unix derivative. People who literally port open-source
software to macOS can say what's most appropriate here better than the
Linux/*BSD community can.

Similarly, Android runs on the Linux kernel, but has its own filesystem
layout that's outside the scope of freedesktop.org.

Post by piegames
Thus, I have the following idea: if we set the default value for
$XDG_DATA_HOME, $XDG_CACHE_HOME and $XDG_CONFIG_HOME to the respective
native equivalents for non-Linux platforms, it would make things easier
to adopt on the application side.

You've described what GLib does, in its APIs that wrap the basedir spec,
and I think that makes a lot of sense. GLib's APIs separate the "user"
directory (the one you write to and the highest priority for reading) from
the "system" directories (lower-priority), but you could implement something
very similar in an API that unified them into a single list.

Pseudocode (taken from the documentation, not necessarily a 100% match for
the actual implementation):

def g_get_user_cache_dir():
if XDG_CACHE_HOME is set:
return $XDG_CACHE_HOME
else if not Windows:
return ~/.cache
else:
return CSIDL_INTERNET_CACHE
(typically C:\Users\me\Local Settings\Temporary Internet Files)
(this is not a perfect match, but it's good enough...)

def g_get_user_config_dir():
if XDG_CONFIG_HOME is set:
return $XDG_CONFIG_HOME
else if not Windows:
return ~/.local/share
else:
return CSIDL_LOCAL_APPDATA
(typically C:\Users\me\Local Settings\Application Data)

def g_get_system_config_dirs():
if XDG_CONFIG_DIRS is set:
split and return it
else if not Windows:
return /etc/xdg
else:
return CSIDL_COMMON_APPDATA
(typically C:\Users\All Users\Application Data)

def g_get_user_data_dir():
if XDG_DATA_HOME is set:
return $XDG_DATA_HOME
else if not Windows:
return ~/.local/share
else:
return CSIDL_LOCAL_APPDATA
(typically C:\Users\me\Local Settings\Application Data)

def g_get_system_data_dirs():
if XDG_DATA_DIRS is set:
split and return it
else if not Windows:
return /usr/local/share, /usr/share
else:
return CSIDL_COMMON_APPDATA, CSIDL_COMMON_DOCUMENTS,
calling DLL's ${prefix}/share, GLib's ${prefix}/share,
program's ${prefix}/share

Qt does something similar in QStandardPaths::standardLocations, although
the details are different on Windows. In particular, the Qt API
distinguishes between roaming and local directories, which doesn't matter
on freedesktop.org platform but does matter on Windows.

I think Qt's approach is probably necessary if you want "first-class
citizen" support for Windows - GLib's simpler API more closely resembles
the basedir spec, but it cannot capture the distinction between local
and roaming directories on Windows.

smcv

[e***@markus-raab.org]

Dear XDG List,

Post by piegames
in discussions around applications adopting the basedir specification,
the handling of non-Linux systems (especially Windows and MacOS) is
something that really comes up a lot.

Yes. Env vars were obviously the most convenient solution for
implementation/adoption but are a big compromise on many other aspects,
even on Linux, e.g., with support of cron, at, sudo, ... It simply lacks
an easy mechanism how to globally change the XDG variables and this is
probably also the main criticism Windows+MacOS folks have, as they are
used to have a global place to change configs "which simply works".

Post by piegames
*Technically*, the specification is platform-independent, as it only
depends on the concept of environment variables. However, this is not
an accepted solution, as it is not native to these respective
platforms. Instead, a common solution is to use the specification only
on Linux and the respective native equivalents on other platforms.

I also think that XDG envs in its current form are practically not
platform-independent (although I agree that they technically are). Which
is also why Elektra https://www.libelektra.org has different resolving
techniques for the path names of configuration files for different
operating systems.

Post by piegames
Thus, I have the following idea: if we set the default value for
$XDG_DATA_HOME, $XDG_CACHE_HOME and $XDG_CONFIG_HOME to the respective
native equivalents for non-Linux platforms, it would make things easier
to adopt on the application side. I am not sure if this is a breaking
change, as the specification is not really explicit whether it even
applies to other platforms at the moment.

I don't think the "setting the default" would be a breaking change, the
spec does not say where the environment variables are set.

Post by piegames
A disadvantage is that – at least on Windows – the destination paths
are not computable anymore, and the Known Folders API needs to be
called in order to get the values.

Yes, it would be a compromise but probably still be an improvement.

As temporary (compromise) solution it probably makes sense to set the
XDG env vars:

1. on Windows/MacOS with dedicated startup scripts reading from APIs
like KnownFolders
2. on Linux with a script that gets XDG vars from Elektra to have a
global place to set XDG vars, with the script executed at all places
like login shells, desktop environment, at, cron, sudo, ...

Btw. in Elektra we played around with intercepting getenv via
LD_LIBRARY_PATH. The current implementation does not work in Windows but
it would allow the return value to be computed at runtime.
https://www.libelektra.org/tutorials/intercept-environment
But also this can only be called transition solution.


As long term solution I would prefer to make the basedir specification
independent of the implementation detail of environment variables, so
that it can be directly integrated in Elektra.

Specifically, I would like to have https://www.libelektra.org and other
portable config abstraction mechanisms to be completely compliant to the
basedir specification, which would require allowing to get/set the XDG
variables via other mechansims (not only env vars).

best regards,

[Chanslor Rosenthal]

Date: April 27, 2021 at 11:03:23 AM PDT
Subject: Re: RCF: Basedir specification for non-Linux
For what it's worth, I do not (frequently) port to Mac, but I *do* frequently develop for Linux on Mac. I work on an outdated MBP, test against my Debian server and Manjaro desktop, a newer Mac, and sometimes other Linux devices.
I mention this because, when I do that, I almost always leave the spec unchanged *for user files*. Things don't get tricky until you arrive at executables.
Things get *very* tricky when you arrive at executables. "Straight" Unix programs are, for the most part, where they are supposed to be, but desktop Mac programs work more like an AppImage and do not live anywhere nor have anything resembling a desktop entry.
Special-casing it may be the only good solution. Some kind of parser would probably be the easiest solution, a companion package that locates Mac locations from FreeDesktop-specified paths and envvars.
Just my two cents. Other people do much more intensive work porting full desktop apps and etc.

[Bollinger, John C]

Indeed, inasmuch as Mac software packaged in “app” format is expected to be pretty much self-contained, it may not make sense for such software to consult $XDG_DATA_DIRS or $XDG_CONFIG_DIRS. Their default data and configuration would normally be packaged together with them, instead. User-specific data and configuration can still be read from $XDG_DATA_HOME and $XDG_CONFIG_HOME, however, and can still override built-in defaults.

However, a Mac app that wants to rely on XDG basedir and standard tools supporting that also has the alternative of using a wrapper script or similar mechanism to set appropriate (internal pointing) values of $XDG_DATA_DIRS and $XDG_CONFIG_DIRS. That seems a bit of a hack, but not necessarily inappropriate under the circumstances. The self-containment of this installation format is fundamentally at odds with the basedir concept of multiple applications sharing system-wide configuration and data locations.


Regards,

John Bollinger


From: xdg <xdg-***@lists.freedesktop.org> On Behalf Of Chanslor Rosenthal
Sent: Tuesday, April 27, 2021 1:06 PM
To: ***@lists.freedesktop.org
Subject: Re: RCF: Basedir specification for non-Linux

Caution: External Sender. Do not open unless you know the content is safe.

Forwarding my own message to the list because my client failed to reply-to the list. I am embarrassed. Apologies to ***@markus-raab!


Begin forwarded message:
From: Chanslor Rosenthal <***@icloud.com<mailto:***@icloud.com>>
Date: April 27, 2021 at 11:03:23 AM PDT
To: ***@markus-raab.org<mailto:***@markus-raab.org>
Subject: Re: RCF: Basedir specification for non-Linux
For what it's worth, I do not (frequently) port to Mac, but I *do* frequently develop for Linux on Mac. I work on an outdated MBP, test against my Debian server and Manjaro desktop, a newer Mac, and sometimes other Linux devices.

I mention this because, when I do that, I almost always leave the spec unchanged *for user files*. Things don't get tricky until you arrive at executables.

Things get *very* tricky when you arrive at executables. "Straight" Unix programs are, for the most part, where they are supposed to be, but desktop Mac programs work more like an AppImage and do not live anywhere nor have anything resembling a desktop entry.

Special-casing it may be the only good solution. Some kind of parser would probably be the easiest solution, a companion package that locates Mac locations from FreeDesktop-specified paths and envvars.

Just my two cents. Other people do much more intensive work porting full desktop apps and etc.

________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer