Feature request: store passes in app-specific subfolder

[waltmck]

Thank you for the nice app! I am interested in syncing my passes between my computers and my android phone. However, this app seems to dump imported passes directly in .local/share. This behavior may theoretically interfere with another application which stores passes in the same location, and it makes it difficult to sync/backup passes without backing up the entirety of .local/share.

I propose moving passes to .local/share/passes or something similar, or to at least make the location configurable (I would personally prefer ~/Wallet).

[pablo-s]

Thank you @waltmck!

If your passes are being stored there, that means you are not using the flatpak version, which should store them inside the application data directory.

What distribution are you using?

Probably the best would be to contact the person responsible for the packaging of Passes for your distribution.

[waltmck]

Hi Pablo,

I am using NixOS, where this project is packaged by nixpkgs. The application fairly simple, so the packaging is trivial--it pretty much just builds the project from source and runs it without containerization. Unfortunately, I don't see a build-time flag to control where the application stores passes--I suppose that the package maintainer could wrap your application with a script that sets $XDG_DATA_HOME = .local/share/passes, but this would be a dirty hack. Generally, my impression is that XDG Base Directory spec compliance is typically the responsibility of upstream rather than the package maintainer.

What would your suggestion be to package your application, specifically? I would be happy to work on a pull request to nixpkgs.

[fossdd]

Generally, my impression is that XDG Base Directory spec compliance is typically the responsibility of upstream rather than the package maintainer

I'm not sure I understood you correctly, but passes rightnow uses XDG_DATA_HOME.

passes/src/model/persistence.py

Line 29 in cf7a925

self.__data_dir = GLib.get_user_data_dir()

This function calls glib and asks for the user data dir (https://docs.gtk.org/glib/func.get_user_data_dir.html) which returns a directory using XDG_DATA_HOME according to the XDG Base Directory Specification.

[waltmck]

Yes, you are correctly using $XDG_DATA_HOME. The problem is that you are directly dumping (not necessarily uniquely named) files into $XDG_DATA_HOME without creating your own namespace (i.e., $XDG_DATA_HOME/passes). Since the XDG standard is meant to support multiple applications which share $XDG_DATA_HOME, this could clearly create some incompatibility.

This is why the standard is for each application to create their own subdirectory--for instance, this is my .cache folder:

Almost all of my applications have their own subdirectory (best), and the standalone files which aren't in their own subdirectory are prefixed by the name of the application to prevent collisions (better). Admittedly, after reading through the actual XDG spec they could be more precise about this requirement, but it is definitely a de-facto standard and it is a common-sense requirement to prevent unanticipated interference between applications.

I don't mean to come in and tell you how to write code for your project, but this seems like a minimal change in order to increase compatibility and standards compliance while making the app easier to use for my use case. I would appreciate it if you would consider it, though of course it is up to you.

[fossdd]

Ah, yeah now I understood you correctly. I looked onto other implementations of g_get_user_data_dir and they also append their app name (sometimes app id). This should be changed, but now that we already use the old location, we have to migrate the old files to the new location 😄