py3status.data store path

[cyrinux]

Maybe I have miss reading yet... py3status.data is store in $HOME, should be in $HOME/.cache for example, what must I set to do this?

[lasers]

what must I set to do this?

You must make a PR. Start with Origin PR #583 and figure it out from there. Using $HOME/.cache is probably a good place for storage.

The py3status.data follows the config so I assume you're using ~/.i3status.conf. You can try and move the config to ~/.config/i3/ or ~/.config/py3status. It would be nice if py3status can follow $XDG_CACHE_HOME.

EDIT: https://github.com/lasers/py3status/tree/storage-xdg_cache_home

[cyrinux]

Issue for me with this PR

[lasers]

Leave this open if you want that PR to be merged... so we'll know where you stand. This might warrant a discussion. Here we go...

So this is a question of whenever we ought to view this as storage file or a cache file. The settings already are permanent / available in the config. And that maybe it's too early to tell because we don't have enough modules using storage methods.

If I used py3status with different configs in different locations, does it mean the storage files will be spawn in three different locations? Yes...

a
├── py3status.data
└── py3status-a.conf
b
├── py3status-b.conf
└── py3status.data
c
├── py3status.data
└── py3status-c.conf

What does this mean to have three different configs in same locations? I think this is a bug because too many users probably would set different configs for different bars in same location so things are not being stored properly... and that modules can get wrong data.

To my masters... I do not mind having storage files in $XDG_CACHE_HOME instead of sitting next to my configs, but I want to have the storage files following the config names too to keep things clean.

If not $XDG_CACHE_HOME, then maybe we could use $XDG_CONFIG_HOME/py3status.

[cyrinux]

I agree with that, should be able to have one storage per bar. Follow config name is a good idea.

[lasers]

I tested this just now. Indeed, it's a bug because I scroll a clock, restart... then all 3 clocks are in same positions... With separate storages, they are in different positions doing their own things.

Few possibilities I can think of...

1) $XDG_CACHE + following config names. Seems easy and clean. Maybe not flexible.
2) Offer py3status { storage_path = '/path/where' } in the config. Seems like lot of work for users, but more flexible. If users does not set it, then I guess $XDG_CACHE + following config names.

3) Do we want to default all bars with one storage or all bars with all storage? The first one is probably fine (for now), but acknowledge that this might be a problem... and could cause more problem as more modules starts to use storage methods.
4) I found another bug. /tmp never worked in first place. I have been tricked by my masters.

[cyrinux]

• +1 for option 2.
• IMO, point 3 seems to be headache for too few cases, 1 bar=1 cache should be sufficient.

[lasers]

5) Storage files also can be stale if users decide to rename their configs not thinking about them. Telling users to rename their storage files / caches seems like a pain in the ass... so treating storage files as caches could be a good thing. Maybe offer storage_path (file) instead of storage_path (dir) too so it can survive this... but I hadn't come up with a solution for default (unset) storage files to be able to survive config renaming. EDIT: Any suggestions?

[cyrinux]

• About 2 I have read too quick, I read storage_path (file) as you say in point 5.
• What about have only one cache file but a config_name which can be default if unset.
  Then add a top-level in storage model.
• But user should be able to delete cache easily without doubt...seems hard to edit the cache file with the way it is for the moment.

[lasers]

I pushed a (rfc) commit.

# example config
py3status {
    # permanent storage files
    storage_file = '~/.config/py3status/bar-top.storage'
    storage_file = '~/.config/py3status/bar-bottom.storage'

    # if unset, use cache file (shared)
    storage_file =  '~/.cache/py3status_cache'
}

[lasers]

Closed via https://github.com/ultrabug/py3status/pull/1411.