linux-cli-community
linux-cli-community copied to clipboard
Use XDG Base Directories
The XDG Base Directories are currently unsupported. You can find the specification here. A brief summary is available on the ArchWiki.
Using the specification gives the user more flexibility in where certain files should go. Programs can also take advantage of the directories being used by, for example, having backup programs exclude $XDG_CACHE_HOME
.
Which files go where should be discussed. My proposal would be:
-
TEMPLATE_FILE
doesn't appear provide any user-specific content so it would be placed into$XDG_CACHE_HOME
-
CONFIG_FILE
is a configuration file and should go into$XDG_CONFIG_HOME
-
SERVER_INFO_FILE
goes into$XDG_CACHE_HOME
-
SPLIT_TUNNEL_FILE
goes into$XDG_DATA_HOME
-
OVPN_FILE
goes into$XDG_DATA_HOME
-
PASSFILE
goes into$XDG_DATA_HOME
- Log files of any sort have been put into
$XDG_CACHE_HOME
. It should be noted that there are programs which handle this differently. - Backups are user-specific and have been put
$XDG_DATA_HOME
In order to not break any current configurations, it will first be checked if "$HOME/.pvpn-cli"
exists and if it does it will be used as the directory in which all files would be placed (as before).
The function purge_configuration
currently deletes everything in the config directory. For now, I have kept it that it only deletes the configuration file, this could be changed to also delete everything in the data and/or cache directory.
Thank you for your contribution.
How much did you test this already?
What I don't like that much is that even when the xdg variables aren't defined it defaults to the "recommended" paths.
This would also require documentation about each file and where it would be located. Which is currently quite easy: Everything is in ~/.pvpn-cli
.
How much did you test this already
So far I have made sure that all the path files are set correctly. I have not extensively tested functionality. I'll make sure to run more tests once we have agreed on where everything should go.
What I don't like that much is that even when the xdg variables aren't defined it defaults to the "recommended" paths.
It is what is stated in the specification and is followed by many programs. No distributions I am aware of set the environment variables by default yet ~/.config is used by various programs.
This would also require documentation about each file and where it would be located.
Where would you suggest we put this? Would it be sufficient to write it into the README?
So far I have made sure that all the path files are set correctly. I have not extensively tested functionality. I'll make sure to run more tests once we have agreed on where everything should go.
One thing I've noticed is that you can't use it anymore when the base directories don't exist already. (~/.local/share
)
Where would you suggest we put this? Would it be sufficient to write it into the README?
Probably DOCUMENTATION.md or something the like, (doesn't exist yet, but very much needed in the future) which would be for a technical documentation.
One thing I've noticed is that you can't use it anymore when the base directories don't exist already.
They would be created by init_cli()
. Without the XDG directories, the config directory is also created in logger.py
and the user data wouldn't be created.
I could check in order whether the configuration files can be found in the XDG directory (if the environment variable is set or the default if it is not set) and then the home directory. If no files are found the user is told to run protonvpn init
and the program exits.
Probably DOCUMENTATION.md or something the like
Would this only be an internal documentation? Where configuration files are stored should also be available to users, so a man page would be pretty good. Though this should probably be a separate issue.
They would be created by init_cli(). Without the XDG directories, the config directory is also created in logger.py and the user data wouldn't be created.
Not in the current form. It's basically mkdir
vs mkdir -p
.
Would this only be an internal documentation? Where configuration files are stored should also be available to users, so a man page would be pretty good. Though this should probably be a separate issue.
Not sure what you mean by internal. It would just be another file in this git repository.