use xdg directories - Githubissues

pseyfert commented 5 years ago

draft for #11, just to put it out there.

Note: at the moment I'm doing lazy evaluation. If the user specifies a local_aur directory, default_blinky_dir is not called. I doubt the benefit (runtime performance, not importing/not relying on xdg being installed) is worth the spaghetti code in scripts/blinky.

I did not (yet) split data/cache (didn't see any config to split further).

EDIT: oh, and this is void of any transition strategy for users from ~/.blinky to $XDG…

pseyfert commented 4 years ago

any feedback on the approach? (I.e. good idea / throw away and do differently. ideas for how the transition should happen?)

cherti commented 4 years ago

oh, sorry, that one somehow slipped through. I'll take a look asap, but I do think that this is a good way forward and it'll be merged.

pseyfert commented 4 years ago

We should discuss if we want to put the at least the build-files to XDG_CACHE_DIR instead of XDG_DATA_DIR.

On a technical level, pacman writes its downloaded packages to /var/cache/pacman/pkg, to be consistent with this, we might want to keep the packages built in XDG_CACHE_DIR as well. However, in case of pacman the cache is not crucial as packages are available on the Archlinux archive, in case of blinky the cache might be more relevant as things need to be built, which can be time consuming, so it might be more advisable to keep the package cache in the XDG_DATA_DIR as well.

@pseyfert , what are your thoughts on this?

I agree that the blinky package cache is more valuable for a user than the pacman cache. Esp. I regularly use the blinky cache (running Syu in some terminal somewhere, sudo times out, running Syu and get a quick install from cache), I doubt I use the pacman cache (i mean … that would require installing a package, uninstalling, and installing again … not overly absurd, but rarer than having an update run in the background).

However, I think the blinky package cache is still only a cache. Nothing should be lost if it disappears (assuming reproducible builds, and that storing of edited pkgbuild files works). So the files in there can be deleted at low risk. The XDG cache is also long lived on many systems in my experience. So I claim we face low risk of annoyance by puting packages in the cache. Thinking "loud", I am wondering if the split into cache dir and data dir provides some triage for "omg, emergency, i need to free up disk" situations.

cherti commented 4 years ago

The XDG cache is also long lived on many systems in my experience.

So would you feel comfortable putting said cache into a tmpdir (taking from you the opportunity of a simple downgrade in case you rebooted since the last install of a package)?

I think the triage would not be made so much easier as we have -Sc and -Scc which acually take that decision for you by emptying the cache programmatically already, instead of manually.

pseyfert commented 4 years ago

Hm, thinking about it, putting the package cache on a tmpdir would fit what i used it for. (though i wouldn't want to fill my ram with the packages in case the tmpdir is in a tmpfs). tbh I haven't used -Sc and -Scc in a while, probably should.

cherti commented 4 years ago

So I think we should then strive for XDG_CACHE_DIR for ~/.blinky/cache and ~/.blinky/build and XDG_DATA_DIR for ~/.blinky/reviewed. ~/.blinky/logs should go to XDG_CACHE_DIR as well, I think, making ~/.blinky superfluous in the end.

This would also mean that we either

need to introduce CLI-arguments for the cache- and data-directories (as we currently have one flag --local-path
we remove --local-path alltogether, instead having this configurable via XDG-enviroment-variables
not introduce two separate arguments but instead keeping --local-path and if it is set we use the local path like the current blinky-directory is used

Furthermore, I think the best way to approach backwards-compatibility is checking for an existing ~/.blinky, if that exists print a deprecation warning but use it, if it doesn't use the XDG-directories. This way we can leave the migration to the users but still kick out the legacy-directory support latest with the 1.0.

@pseyfert your thoughts on this?

pseyfert commented 4 years ago

It depends how much flexibility you want to leave for users. I think for debugging, having a command line argument to quickly use a different blinky-dir is nice. istm your third option adds little maintenance improvement over the first, and the behaviour even seems a bit strange (once a user wants to keep using their data dir but not the cache, a single switch will just be an annoyance. having to specify two directories on the command line for a quick move … hm … it is leaking internal working to "i just want to run this" users, but i guess docs that say "to ignore your local dirs, modify these two" does the job.). Do you assume one could run into problems in the following scenario:

review and edit a package and build it
switch cache and data dir
review a package w/o editing and build it
uninstall the package
use the cache from the first build and the data dir from the second build. try to reinstall the package
the approved pkgbuild is found, in the build cache a built package is found and not rebuilt, the package with edits is installed.

cherti commented 4 years ago

Good points indeed. However, if we support XDG_CACHE_DIR and XDG_DATA_DIR separately (as we should), we can no longer guarantee with absolute certainty that both directories stay in sync anyways (in case a user sets one differently, but not the other). Therefore I don't think we should try to enforce what we cannot and just let it be.

And as we have XDG_DATA_DIR and XDG_CACHE_DIR, I think we can simply safely omit the --local-path. Users with the intend of simpler debugging should simply set those variables to a temporary one then.

cherti commented 4 years ago

lgtm, thanks!

as Github seems incapable of merging this, I'll take the source and apply it manually, though.

cherti / blinky

use xdg directories #12