Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use platform specific directories #45

Open
jtojnar opened this issue Apr 30, 2017 · 6 comments
Open

Use platform specific directories #45

jtojnar opened this issue Apr 30, 2017 · 6 comments
Assignees

Comments

@jtojnar
Copy link

jtojnar commented Apr 30, 2017

On Linux XDG basedir specification should be followed. That means the database should be stored in data_dir:

if 'XDG_DATA_HOME' in os.environ:
    data_dir = os.path.join(os.environ['XDG_DATA_HOME'], 'cum')
else:
    data_dir = os.path.join(os.environ['HOME'], '.local', 'share', 'cum')

And the configuration file in config_dir:

if 'XDG_CONFIG_HOME' in os.environ:
    config_dir = os.path.join(os.environ['XDG_CONFIG_HOME'], 'cum')
else:
    config_dir = os.path.join(os.environ['HOME'], '.config', 'cum')
@Hamuko
Copy link
Owner

Hamuko commented Apr 30, 2017

Not sure if I like the idea of spreading our load across all over the file system. Also, since cum is not not Linux software, we have to add additional check to see if we are on Linux and then check the variables. @CounterPillow can probably chime in on the Linux shit.

@CounterPillow
Copy link
Collaborator

CounterPillow commented Apr 30, 2017

Even if freedesktop is a source of shitty standards nobody correctly implements, I'm not really against this as long as we keep the cumdir option to mean "both locations in this one place" so we don't have to muck about with environment variables when testing. I have both applications that implement the XDG basedir spec and applications that just dump things into dot-dirs in ~ on my system.

That being said, I prefer currently working code to code that has not yet been written, requires existing cum users to move their files, and is going to introduce platform-specific behaviour. So I'd like to hear one problem this solves other than just "freedesktop has a standard on it", but then again I'm not the one making decisions here.

@jtojnar
Copy link
Author

jtojnar commented Apr 30, 2017

The main reason for using XDG specs are easier backups. Ideally, I would just archive the contents $XDG_CONFIG_HOME and $XDG_DATA_HOME.

@haasn
Copy link

haasn commented Apr 30, 2017

+1 on XDG when implemented properly, since it does make organizing backups etc. significantly easier - anything that's in ~/.config I can just universally check for changes, whereas for various other dotfiles I need to manually whitelist configuration-type files.

(Then again, some applications violate XDG or do stupid things with their configuration so I need to manually inspect anything anyway. But at least it makes it easier to populate the list of things to inspect)

@jtojnar XDG_CONFIG_HOME etc. isn't an environment variable, at least not on my system.

@CounterPillow
Copy link
Collaborator

@haasn

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

You simply haven't set XDG_CONFIG_HOME, so you're using the default location.

Since I'm currently the only contributor using cum on Linux, I'll look into implementing this in the near future unless @Hamuko disagrees. Though as always, feel free to submit a PR yourself if I'm being slow.

@haasn
Copy link

haasn commented Apr 30, 2017

Oh, never mind my comment. I thought you were proposing the logic of using XDG if $XDG_CONFIG_HOME exists and falling back to the non-XDG location otherwise. I didn't read the code closely enough.

CounterPillow added a commit that referenced this issue Aug 7, 2017
Fixes #45

We fall back to using the old cum directory if the new schema doesn't
exist but we can find an old cum directory.

config.cum_dir is no longer a global; instead, config_dir and data_dir
should be used regardless of platform.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants