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

Allow a saner, cleaner and standard default linux conf file storage location #58

Closed
wants to merge 1 commit into from

Conversation

jaseg
Copy link

@jaseg jaseg commented Feb 10, 2014

As discussed in PR #49, allow ~/.anki to be used as a configuration directory without changing the default. Though I still think PR #49 would be the better solution.

@pjf
Copy link

pjf commented Feb 10, 2014

Didn't Anki 1.0 use ~/.anki as a storage directory? The reason I ask is that I definitely have a ~/.anki directory already, so we probably want to be careful if we pick up an old version's files by accident.

Having said that, If we actually want to go with standards, then I'd highly suggest the XDG Base Directory Specification, which is widely adopted by Debian, Ubuntu, and most other modern *nix systems.

This would place the config in ~/.config/anki if no $XDG_CONFIG_HOME is set, and data files in ~/.local/share/anki if no $XDG_DATA_HOME is set.

The big advantage of using the XDG standard is that operating systems and users can specify how they'd like files stored. It makes it much easier to produce portable apps, which can run on a USB key (you set your XDG root to the USB key, and you're done!). And if you do a git init at the top of your $XDG_CONFIG_HOME, then you can keep all your config files under revision control.

@dae
Copy link
Member

dae commented Feb 10, 2014

As I said in the previous PR, I am considering moving to Documents/Anki to bring it in line with other platforms, but will not use a dotfile as there are too many Linux users who aren't familiar with them and risk failing to back up their data. If you want to use ~/.anki or some other path on a USB stick, that is what the -b option is for.

@porcoesphino
Copy link

Keeping things simple is nice but the extra clutter is a tradeoff. What use case are you describing that isn't covered by the auto-backup and sync? (revisioning + data recovery/mutiple devices). Something like time machine on a mac?

@dae
Copy link
Member

dae commented Feb 10, 2014

There was more than one case in Anki 1 where users moved their files to
another computer and then realized they'd forgotten about Anki, or posted
support requests because they couldn't locate their files.

On Mon, Feb 10, 2014 at 9:16 PM, porcoesphino notifications@github.comwrote:

Keeping things simple is nice but the extra clutter is a tradeoff. What
use case are you describing that isn't covered by the auto-backup and sync?
(revisioning + data recovery/mutiple devices). Something like time
machine on a mac?

Reply to this email directly or view it on GitHubhttps://github.com//pull/58#issuecomment-34625204
.

@aleksejrs
Copy link

I am considering moving to Documents/Anki to bring it in line with other platforms, but will not use a dotfile as there are too many Linux users who aren't familiar with them and risk failing to back up their data.

Do many people actually use Documents/ and would look into it already? And if Documents/ is separate from Pictures/ and Music/, isn't it for word processor output?

@jaseg
Copy link
Author

jaseg commented Feb 11, 2014

On 02/11/2014 07:09 PM, aleksejrs wrote:

I am considering moving to Documents/Anki to bring it in line with other platforms, but will not use a dotfile as there are too many Linux users who aren't familiar with them and risk failing to back up their data.

Do many people actually use Documents/ and would look into it already? And if Documents/ is separate from Pictures/ and Music/, isn't it for word processor output?
Documents is quite widely used. You are right in that it is intended to be used for word processor output, indeed .config is just the place for application-specific databases.

@franklincm
Copy link

I completely agree with vaab in the referenced PR. Hard coding either ~/Anki or ~/Documents/Anki is unnecessary. There's already a well established convention here, but this should still be left for a user to specify.

@dae dae closed this Mar 14, 2014
@jcrben
Copy link

jcrben commented Feb 12, 2017

@dae how about an environment variable to customize the location, rather than a command-line option?

@dae
Copy link
Member

dae commented Feb 12, 2017

I have no fundamental objections to that, but does it really buy you much over a command line flag?

@jcrben
Copy link

jcrben commented Feb 12, 2017

It would help me a fair bit. I don't use the command-line flag right now as it's annoying to configure the mac Spotlight to use it (not sure how to do that) which applies similarly to running programs in other OSes.

Nearly all of the data/config for the programs I use is gathered into consistent places (following the XDG standards - XDG_CONFIG_HOME, XDG_DATA_HOME, etc) on mac and Linux, in part using a bunch of environment variable flags to set the location for mac programs which don't recognize the XDG variables. It makes switching back and forth between Linux and mac much easier.

Anki's data is symlinked into a same place, but that symlink is more of a hassle than an environment variable and as we saw the Documents location messed with things on mac recently...

@dae
Copy link
Member

dae commented Feb 15, 2017

I've added it to the dev code.

@jcrben
Copy link

jcrben commented Mar 11, 2017

nvm the below, looks like this is the commit: 88d8be3

ANKI_BASE is the env variable.


~~~Looks like there's no environment variable to customize the location from platform defaults if you're not using Linux? I'm using a Mac but trying to stay platform-agnostic so I'm using a mixture of XDG_* variables (when used by Mac, e.g., git) and custom variables (e.g., something like ANKI_PROFILE_LOCATION) to keep the locations of things consistent...~~~

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

Successfully merging this pull request may close these issues.

None yet

7 participants