What's the difference between state_dir and data_local_dir?

[rosefromthedead]

On Windows, data_local_dir is LocalAppData which AIUI is like RoamingAppData but not synchronised across machines. The docs for state_dir say that it's not synchronised across machines. Are they not the same thing? If they are, could data_local_dir's behaviour on Linux be changed to match state_dir? Currently state_dir is only useful on Linux, and to me it would make sense to merge it into the existing data_local_dir function.

[redianthus]

In ocamlpro/directories I made the choice to have state_dir being the same as cache_dir in macOS and Windows because I believe it's the closest thing to it.

[soc]

The state dir has some very specific requirements and guarantees compared to the cache dir.

My reasoning was that filling in cache dir for state dir on Windows/macOS feels wrong:

• Either you need need state dir's additional behaviors – then pretending Win/macOS offers them is bad;
• or you don't need them – then simply use the cache dir.

(All the above applies the same if you replace "cache dir" with "data local dir".)

[redianthus]

I don't believe these additional behaviors are "needed" and there's also no guarantees:

The $XDG_STATE_HOME contains state data that should persist between (application) restarts

It says should and not must. They're just some nice things to have when possible. Thus:

• either you want them if available (but it wouldn't be an issue if they're not) – then pretending Win/macOS offers thems is OK ;
• either you don't want them – then simply use the cache dir.

A basic use case is an interpreter (e.g. python, or utop in my case) where you would like to keep an history of the commands entered by the user. Clearly the history file fits better in state dir, but it doesn't hurt to put them in cache dir when state dir is not available.

[soc]

I don't believe these additional behaviors are "needed" and there's also no guarantees:

Ah sorry, I had state dir switched with runtime dir in my head. That makes my argument weaker in that regard, as the runtime dir has higher requirements.

A basic use case is an interpreter (e.g. python, or utop in my case) where you would like to keep an history of the commands entered by the user. Clearly the history file fits better in state dir, but it doesn't hurt to put them in cache dir when state dir is not available.

I think this would be fine for this use-case, but I'm not sure it applies to every use-case of the state dir though. In the end, the library isn't meant to make (and can't make) such determinations that work for everyone.

In your case, writing code that picks the state dir on Linux and the cache dir on Windows/macOS would be a perfectly valid solution.

[redianthus]

Ah sorry, I had state dir switched with runtime dir in my head. That makes my argument weaker in that regard, as the runtime dir has higher requirements.

Indeed, they're different. :smile:

Let's say you have to use state dir. On Linux, fine. Then you're on macOS or Windows and it's not available, which directory are you going to use ? Not data dir (users don't want to backup states...), you're left with cache dir. Then, I prefer the library to pick it for me automatically instead of having to write code to choose cache dir when state dir is not available.

But if you find a use case where this is not true, I'll be interested ! :)