XDG support

[dvdesolve]

At the moment Artemis software requires that working directory should be writeable to be able to download database. Also it requires that themes should reside in this directory too. This requirements make usage of Artemis a bit inconvenient with packaging utils and different users.

There exists well-established specification - XDG Base Directory - which could solve issues described. It's very easy to implement - all you need is to check if XDG_DATA_HOME is set otherwise consider $HOME/.local/share/artemis as local data directory to store database and/or themes.

This will ease dealing with database maintenance (downloading and updating) and themes a lot for per-user configurations and for using with package managers. It's even possible to store configs transparently in $XDG_CONFIG_HOME/artemis (or in $HOME/.config/artemis) so potential multi-user usage will be very simple. I believe there exist analogous scheme for Windows-like OSes.

Also it will make possible to run Artemis from any other directory.

What do you think?

[alessandro90]

Hi, Everything is stored in a single folder for basically 2 reasons:

1. To be the same for all operating systems.
2. (this is a personal reason) I think it is easier to have everything about a program in just a single folder. So that for example to delete the software you just need to delete such folder.

Also at the moment Artemis is not thought to be used with a package manager.

Actually we didn't think about issues regarding multi-user usage.

About the last issue, if you put the Artemis folder in your PATH you should already be able to run the artemis executable file from any directory (this works only for the 'compiled' file, not the .py script which can be run with python artemis.py).

Anyhow I will look at the XDG Base Directory specification and think about if it is worth it to implement it. I am still not sure about the change.

[dvdesolve]

Yeah, storing everything in one directory simplifies development for different platforms but destroys OS-specific user interface and behavior guidelines. While being portable this way hinders seamless integration with OS. It's always good thing to separate executables, data and cache - by this way you can have only one copy of program installed while every user will have its own cache storage and/or data storage. Moreover, modern installers will provide user a set of options to delete all caches and other local storages.

Actually Artemis will be well-suited for package managers/installators by only implementing XDG specs (for *nix OSes) and similar specs for Windows experience. Right now I'm maintaining a package for Arch Linux and it requires some intervention during setup process to integrate with OS nicely.

If we will have separation logic in Artemis then it will be very easy just to install one single executable (which is quite heavy) in, let's say, /usr/bin and all users on this machine will be able to use it directly while storing themes, database and other potentially necessary things in, for example, $XDG_DATA_HOME/artemis (or $HOME/.local/share).

I've already implemented XDG specs in several apps and in all cases it just was a matter of checking/creating $XDG_CACHE_HOME/appname, $XDG_DATA_HOME/appname and/or $XDG_CONFIG_HOME/appname. In this particular case the only extra thing is to check against OS type/version and act accordingly, but due to the nature of Python language I think it is much easier to implement than, for example, in C/C++. If I'll found spare time I can help to implement this feature.

[MightyPork]

I hit this when installing artemis to /opt system-wide, I had to chmod a+w the /opt/artemis folder or it wouldn't even start because of creating a log file. Log file in opt is really unusual