Taskwarrior: [TW-403] Comply XDG Base Directory Specification

[taskwarrior]

_Akiva Levy on 2013-07-19T01:30:05Z says:_

As per Feature #619

It would be nice if Taskwarrior comply this specification:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

then ~/.task/ appears to be ~/.local/share/task/ or ~/.cache/task/
~/.taskrc can be in ~/.config/task/config
and so on

The reason this was dismissed it dismal and, to be frank, rather shameful. It's a standard for a reason. And while slow to catch on, it has been widely adopted. What makes the reason it was turned down worse is just how simple a fix this feature would have been for all those that would prefer it.

[taskwarrior]

Migrated metadata:

Created: 2013-07-19T01:30:05Z
Modified: 2014-02-09T01:41:51Z

[taskwarrior]

_David Patrick on 2013-07-19T15:55:36Z says:_

I'm not sure if this is a great idea or a terrible idea..
are you suggesting we relocate all tw config files to ~/.config/task/ ?
What would it gain us?
How hard would it be to implement?

[taskwarrior]

_Akiva Levy on 2013-07-19T16:19:19Z says:_

(at)David, it's actually quite simple: at start, the application first searches for the existence of the config and data directories at ~/.config/task/{[configfile],[datafiles]}, falling back to the current ~/.taskrc and ~/.task/ if not found. That is literally the only change. If it helps, I could include an extensive list of all the applications out there that have adopted this standard.

Why would you think it's a terrible idea? As far as I am concerned, centralised and organised data storage + not cluttering my home directory = only good things.

[taskwarrior]

_David Patrick on 2013-07-19T17:17:07Z says:_

Akiva Levy wrote:

(at)David, it's actually quite simple: at start, the application first searches for the existence of the config and data directories at ~/.config/task/{[configfile],[datafiles]}, falling back to the current ~/.taskrc and ~/.task/ if not found. That is literally the only change.

that DOES sound simple..

If it helps, I could include an extensive list of all the applications out there that have adopted this standard.

nope, that's ok, I'm familiar with the standard and have no problems it it, per se.

Why would you think it's a terrible idea?

I didn't say it was a terrible idea, just that I wasn't sure. As you describe it, it sounds fine and reasonable, not everyones cup of tea but an option for those that prefer the ~/.config/ route.

[taskwarrior]

_Wim Schuermann on 2013-07-19T19:56:00Z says:_

Akiva Levy wrote:

(at)David, it's actually quite simple: at start, the application first searches for the existence of the config and data directories at ~/.config/task/{[configfile],[datafiles]}, falling back to the current ~/.taskrc and ~/.task/ if not found. That is literally the only change.

Except that this is not at all what the specification says. You would have to check whether $XDG_CONFIG_HOME is set and only default to ~/.config if it is not. Checking whether @~/.config@ exists and defaulting to @~/.task@ and @~/.taskrc@ would probably be the worst way one could possibly try to implement what the standard specifies. It should be an all or nothing approach, not "let's see what is there and maybe, possibly, use part of a specification".

That said, I am a bit disappointed that this specification has made it this far along the "so many people use it it is now almost a standard" path. In quite literally every discussion about it, people end up misunderstanding what it tries to communicate. A good example of this is your proposal in comment 2 here or issue #619 where Gleb says

then /.task/ appears to be ~/.local/share/task/ or ~/.cache/task/
/.taskrc can be in ~/.config/task/config
and so on

Which is wrong, and not only wrong, but in case of moving @~/.task@ to @~/.cache@ even dangerously so. The specification says that "user specific non-essential data files" should be stored there - a place for data which can be re-downloaded or re-created at any time. Should the user run out of disk space this directory would logically be one of the first to go. Taskwarrior's data files are most certainly _not_ transient data and cannot be re-created on the fly.
@~/.local/share@ (or $XDG_DATA_HOME) is not meant for data like Taskwarrior's pending.data/completed.data/undo.data at all, but for things you can currently find in /usr/share - mostly icons, documentation, examples, (...). Read-only data.

So I guess what I am trying to say is:
I dislike that specification, not because it is a bad idea but because it is apparently so badly written that 90% of people pushing to have it implemented do not understand it. I do not particularly care whether Taskwarrior does implement it, but I think Paul has a lot of potentially more promising work to spend his time on.

In the meantime, here is how to have a combined @~/.config@ folder which can easily be backed up:

$ cd
$ mkdir -p .config/taskwarrior/data
$ mv .task/* .config/taskwarrior/data/
$ mv .taskrc .config/taskwarrior/taskrc
$ rm -rf .task
$ ln -s .config/taskwarrior/data .task
$ ln -s .config/taskwarrior/taskrc .taskrc

There you go, now Taskwarrior uses @~/.config@ for its files!

Tools like "homeshick":https://github.com/andsens/homeshick even automate this process.

[taskwarrior]

_Paul Beckingham on 2013-07-20T00:08:51Z says:_

Taskwarrior allows you to store your .taskrc and .task directory in any location, with any name. This can be done on the command line, or via environment variables. The result is more flexible that this so-called standard.

This "standard" is so poorly written and thought out, uses vague terms and contains undefined behavior. I have never encountered a program that supports this, to my knowledge. IT overrides UMASK - why? It is full of typos - I cannot believe it has been reviewed. It refers to the "sticky bit" but clearly doesn't understand what it is. It stipulates that files must be deleted by applications under conditions encountered outside their runtime.

The document is clearly nonsense. I rejected it 2 years ago. I meant it.

[xerus2000]

In the meantime, here is how to have a combined @~/.config@ folder which can easily be backed up:

$ cd
$ mkdir -p .config/taskwarrior/data
$ mv .task/* .config/taskwarrior/data/
$ mv .taskrc .config/taskwarrior/taskrc
$ rm -rf .task
$ ln -s .config/taskwarrior/data .task
$ ln -s .config/taskwarrior/taskrc .taskrc

There you go, now Taskwarrior uses @~/.config@ for its files!

Except that this totally misses the point, because then my home directory still contains two entries that shouldn't be there...

[tbabej]

Support for taskrc location defined by XDG_CONFIG_HOME implemented in #2316. The other data locations can be then defined in the taskrc file itself.