Supporting XDG Configuration file locations

[quietvoid]

Hi. Thanks for the app, it's working well with my Polar H10.

I was trying to package it on my system (Arch) but got blocked by the default config trying to create a file in system folders (where it's installed, /usr/bin/null-iron-heart). I'm thinking it could be nice to support the XDG specification base directories, such as XDG_CONFIG_HOME.

I know it's supported by crates such as directories-next, so it shouldn't be too complicated to support.

I could look into it and submit a PR but my usecase is quite simple, I don't really need logging and that is also something to consider.

[nullstalgia]

Glad to hear you're enjoying the app!

It sounds simple enough, although it has a couple wrinkles I need to iron out.

I was aware of this possibility, but since my app primarily targets Windows users who are more used to "portable" applications, I prioritized that. However I'm more than happy to support both use cases if possible, if we can avoid confusion with the different behaviors.

Ideally, it would prefer using an adjacent config if it exists, deferring to an Env Var directory config if not. However creating the config is where the wrinkles come in, like you experienced. I don't think checking if the parent directory is write-able is a sane solution, but I can't think of a solid way to seamlessly differentiate.

Having one platform be "portable," while another uses Env Vars, also sounds confusing.

One suggestion I've received is to package an extra portable.txt file with the releases that would tell the application to check in the executable directory, but I feel like a more seamless solution exists somewhere.

I'm open to any other thoughts or suggestions :)

[quietvoid]

What about a build time feature? It's the simplest way to configure whatever default path at build time. Plus it would allow to only add the directories-next dependency when building with the feature enabled.

I did a quick check and there seems to be 3-4 places where current_exe is called. It could possibly be replaced with a wrapper function using the cfg macro to obtain the base directory. It could potentially be a different directory per context, i.e config vs. app logs vs. logged csv.

[nullstalgia]

I think that makes sense, having it be explicitly opt-in at build time; so the release artifacts stay portable, it'll be default portable building from source, but system-level installs are still supported.

It sounds like you'd prefer the different types files in different spots? I haven't written apps in the past with intent that they be installed on a system level, so I just want to make sure that I match the expectations of those users who prefer that. (Especially since my future projects will lean more in that direction, I want to make sure I get it right the first try.)

Cheers for the directories-next mention, by the way, I think I have a better idea of how I wanna tackle this even if I don't choose to use it directly. config_dir for config and data_local_dir for data logging.

The only thing I would have a logic difference in platforms is where application logs are stored, but I think /var/log is fine for Linux and next to data logs is fine for Windows/MacOS. (I'm playing it safe with MacOS as I don't own compatible hardware nor know anyone who can test for me)

[quietvoid]

It sounds like you'd prefer the different types files in different spots?

I don't have a preference. It might also be more convenient for everything to be in config_dir.

[nullstalgia]

It'll be a moment before I poke the codebase again (been focusing on finishing the brown.edu Rust Book, 2/3rds of the way done so far!), so I'll chew on which way I want to go in the mean time.

I'm also considering renaming the crate and repository to just iron-heart to reduce name redundancy, warning you in advance for your package. But that would change at the same time that I push those config-related changes.

Thanks for the insight!