Package: xdgenvpy
xdgenvpyxdgenvpyis yet another Python utility for theXDG Base Directory Specification,
but one that provides Pythonic access as well as a CLI utility.xdgenvpyadheres to the XDG Base Directory spec on Unix systems, and also provides
similar for Windows-based systems.How to usePythonThere are three main ways to use xdgenvpy as a Python package,Retrieve XDG environment variables, or the specification defaults.Determinepackagespecific directories based on the XDG spec.Or pedantically createpackagespecific directories before attempting to
use the directory.To use xdgenvpy as a simple XDG base directory getter, simply create a newxdgenvpy.XDGobject and use the properties it exposes.fromxdgenvpyimportXDGxdg=XDG()print(xdg.XDG_DATA_HOME)# /home/user/.local/shareprint(xdg.XDG_CONFIG_HOME)# /home/user/.configprint(xdg.XDG_CACHE_HOME)# /home/user/.cacheprint(xdg.XDG_RUNTIME_DIR)# /run/user/1000print(xdg.XDG_DATA_DIRS)# /home/user/.local/share:/usr/local/share/:/usr/share/print(xdg.XDG_CONFIG_DIRS)# /home/user/.config:/etc/xdgBut sometimes you want to use package specific directories derived from the XDG
base directories.  This can be done with thexdgenvpy.XDGPackageclass.fromxdgenvpyimportXDGPackagexdg=XDGPackage('mypackage')print(xdg.XDG_DATA_HOME)# /home/user/.local/share/mypackageprint(xdg.XDG_CONFIG_HOME)# /home/user/.config/mypackageprint(xdg.XDG_CACHE_HOME)# /home/user/.cache/mypackageprint(xdg.XDG_RUNTIME_DIR)# /run/user/1000/mypackageprint(xdg.XDG_DATA_DIRS)# /home/user/.local/share/mypackage:/usr/local/share/:/usr/share/print(xdg.XDG_CONFIG_DIRS)# /home/user/.config/mypackage:/etc/xdg')Lastly, you could also usexdgenvpy.XDGPedanticPackageto ensure each of the
package specific directories exist before the calling code attempts to use the
directory.  Instances of thexdgenvpy.XDGPedanticPackageclass will not create
system level directories, only package directories on the DATA, CONFIG, CACHE,
and RUNTIME variables.fromxdgenvpyimportXDGPedanticPackagexdg=XDGPedanticPackage('mypackage')print(xdg.XDG_DATA_HOME)# /home/user/.local/share/mypackageprint(xdg.XDG_CONFIG_HOME)# /home/user/.config/mypackageprint(xdg.XDG_CACHE_HOME)# /home/user/.cache/mypackageprint(xdg.XDG_RUNTIME_DIR)# /run/user/1000/mypackageprint(xdg.XDG_DATA_DIRS)# /home/user/.local/share/mypackage:/usr/local/share/:/usr/share/print(xdg.XDG_CONFIG_DIRS)# /home/user/.config/mypackage:/etc/xdgCLIxdgenvpy also includes a runnable module, which is easily accessible via the
scriptxdg-env.  Pip will normally install scripts under something like:~/.local/binThe installedxdg-envcommand essentially takes a list of XDG variables, and
an optional package name.  For each XDG variable specified,xdg-envwill
print its corresponding value based on the specification.  It can optionally
take the name of a package and include that into the variable's values.But can't we justechothe XDG variables like so?echo${XDG_DATA_HOME}echo${XDG_CONFIG_HOME}echo${XDG_CACHE_HOME}echo${XDG_RUNTIME_DIR}echo${XDG_DATA_DIRS}echo${XDG_CONFIG_DIRS}Well, yes.  But there is a problem when the variables are not defined.  Thexdg-envcommand willalwaysprint a value that adheres to the spec.  If the
environment variable does not exist, then the default value will be returned, as
defined by theXDG Base Directory Specification.Although the Python package supports apedanticmode, thexdg-envcommand
will not change the file system.  Even if a package name is supplied and the
directories do not exist,xdg-envwill not create any files/directories.  This
was simply a design decision to keep the shell command as file-system safe as
possible.How to installInstall locally as a normal user:pip3install--userxdgenvpyOr install globally as the all powerful root:sudopip3installxdgenvpyA Word About WindowsTheXDG Base Directory Specification.
does not mention how the spec should be implemented on Windows-based platforms.
That said, many applications on Windows still follow a very similar convention
to the XDG base directory spec.  And that is to generally place config files
under%APPDATA%/MyPackage/configs.If we squint, it kind of looks like we can simply replace the POSIX tilde~with the Windows%APPDATA%variable.  Then there's a directory that is the
application's name.  And finally, any configs or data files the application
needs to save is under that directory.Generally, xdgenvpy works in this way on Windows-based platforms.  Though this
is not a perfect solution as Windows applications can put configs and data files
under any of the directoriesLocal,LocalLow, andRoaming(where theRoamingdirectory typically is pointed to by%APPDATA%).  Additionally, some
XDG variables do not make much sense on Windows-based platforms.XDG_RUNTIME_DIRis one such example.  On Unix systems it defaults to/run/user/USERID.  There is no close equivalent to a Windows-based directory.
As such, xdgenvpy does not do anything fancy other than prepend%APPDATA%to
most directories and drop any.prefixes for hidden directories/files.That said, if you use xdgenvpy extensively on Windows platforms and would like
better support, create GitLab issues on the project or submit Merge Requests.
Let's all make xdgenvpy as useful as possible, even if it needs to implement XDG
base directory spec-like features on non-Unix platforms.