search

GNUAspell / aspell

http://aspell.net
GNU Lesser General Public License v2.1
243 stars 53 forks source link

Please use XDG basedir paths for user config and data files #560

Open aspell-helper opened 5 years ago

aspell-helper commented 5 years ago

https://lists.gnu.org/archive/html/aspell-devel/2019-01/msg00000.html https://bugs.debian.org/900164

Date: Thu, 31 Jan 2019 07:08:35
From: Agustin Martin <agmartin@debian.org>
To: aspell-devel@gnu.org
Subject: [aspell-devel] Suggestion in Debian#900164: Please use XDG basedir paths for user config and data files

Hi,

We have recevied following suggestion by Guillem Jover, in Debian bug
tracking system, see https://bugs.debian.org/900164

Guillem wrote:

---------- 8< ---------------------------------
The aspell config ~/.aspell.conf and user personal word and replace
files ~/.aspell.LL.prepl and ~/.aspell.LL.pws are read directly from
the user home directory. This makes for an untify home. :)

It would be nice if aspell would support the XDG basedir standard [X]
and those would be looked up first under something like:

  ${XDG_CONFIG_HOME:-~/.config}/aspell/aspell.conf
  ${XDG_DATA_HOME:-~/.local/share}/aspell/aspell.LL.prepl
  ${XDG_DATA_HOME:-~/.local/share}/aspell/aspell.LL.pws

[X] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.htm
---------- 8< ---------------------------------

I also think it would be nice to have a configuration option at build time
to have this behavior or allow it in some way, so I am forwarding this bug
report in case someone thinks it worths (and writes the code).

Regards,

-- 
Agustin
lhanson commented 5 years ago

Please implement, there is no downside to respecting users' preferences.

kevina commented 5 years ago

I think it would be a good idea, but there is the issue of migration when upgrading to a version (or build) that now expects the files in a different location than the previous version. I have not had the time to work out a good solution to the migration problem.

lhanson commented 5 years ago

Most applications tend to look for the files in the specified location and then fall back to the legacy paths if they aren't found. Should make it seamless for users.

eric-s-raymond commented 4 years ago

Yes, please do this. Managing old-school $HOME dotfiles is rather a pain; implementation of the XDG convention would be appreciated.

kevina commented 4 years ago

I think better paths will be:

  ${XDG_CONFIG_HOME:-~/.config}/aspell.conf
  ${XDG_DATA_HOME:-~/.local/share}/aspell/LL.prepl
  ${XDG_DATA_HOME:-~/.local/share}/aspell/LL.pws

I will at very least consider an option to use XDG paths instead of the legacy $HOME dotfiles. I will also provide a compile time option to make the XDG paths the default.

iandstanley commented 4 years ago

I think it would be a good idea, but there is the issue of migration when upgrading to a version (or build) that now expects the files in a different location than the previous version. I have not had the time to work out a good solution to the migration problem.

not really

the XDG specification recommends that the following is used for

  1. If the XDG config directory ($XDG_CONFIG_HOME/appname) for the app is there use it
  2. Check if the ~/.oldstyle_config_dir is there if so use that
  3. There is no config file so create a directory $XDG_CONFIG_HOME and put new config files in there and use them

That way an app updated by the user issuing apt update && apt upgrade (or equivalent) will not break an existing system

The existing user will continue to use the existing directory until he/she/?? moves the config manually.

No apps should be migrating the config directory on behalf of the user just because it changes where it wants to store them. Users won't find config directories go missing if they are not aware of XDG

The user can either:

kevina commented 4 years ago

@iandstanley

the XDG specification recommends that the following is used for

A citation is needed, the XDG Base Directory Specification as provided on specifications.freedesktop.org doesn't mention any of this as far as I can tell.

iandstanley commented 4 years ago

sorry I mispoke I meant to say that a lot of apps take that fallback position (I misread the fallback to the default .config dir which wouldn't help with backwards compatibility)

Just a few examples of this approach

https://git-scm.com/docs/git-config http://web.mit.edu/git/www/git-credential-store.html https://manpages.debian.org/testing/tig/tig.1.en.html