twpayne / chezmoi

Manage your dotfiles across multiple diverse machines, securely.
https://www.chezmoi.io/
MIT License
13.4k stars 493 forks source link

How to handle versioned settings directories? #1871

Closed VorpalBlade closed 2 years ago

VorpalBlade commented 2 years ago

What exactly are you trying to do?

I want to figure out a way to deal with software that use versioned folders under ~/.config. For example the various JetBrains IDEs (PyCharm, IntelliJ etc), SmartGit and so on. (Come to think of it, it seems it is mostly closed source software that does this?)

What they do is create a directory structure like:

~/.config
 - MySoftware
   - 1.2.3
      config.json
      other files
   - 1.2.4
      config.json (migrated from the previous version on updating the software, possibly with large changes, possibly unmodified)
     ...

There are obvious problems to handling these config files in chezmoi, yet it would be useful to perform the two core features of chezmoi:

  1. Sync settings between computers
  2. Set up some default settings on new computers.

Just plain adding whatever the current file is to chezmoi will run into problems when the software is updated. I don't really see a good clean way to handle this, so maybe we are looking for what the least bad option is. Since these settings files are generally updated inside the program they should generally be symlinks into the chezmoi directory as well.

What have you tried so far?

So far I have thought about possible solutions that would work well and come up with nothing good.

The best I can think of is a custom run_ script to handle this for checkout and a custom script in ~/bin to handle updating the chezmoi state (I imagine that updating the chezmoi state from a run_ script is not a good idea!). A systemd timer could possibly be set up to run the script regularly.

Where else have you checked for solutions?

Output of any commands you've tried with --verbose flag

Not applicable, I got stumped before reaching the point of running any actual commands.

Additional context

Side note: When I said "possibly with large changes" with regards to the differences after migration of these files between software versions above, I was not kidding by the way. SmartGit migrated from XML to JSON for the main settings file a few versions ago! Those changes (file name changes) can probably not be handled automatically. But I would like to see simpler changes be handled automatically (somehow). I hope I'm not asking for the impossible here.

Second side note: There should be an easier way to add an existing setting file as a symlink. Like a flag to chezmoi add that automatically moves the file into an ignored directory in the chezmoi repo and adds the requisite symlink template.

twpayne commented 2 years ago

Would using symbolic links in the ~/.config/MySoftware directory be sufficient? For example you might have:

~/.config
  - MySoftware
    - config
        config.json
        other files
    - 1.2.3 symlink to config

You can then manage the ~/.config/MySoftware/config directory and the ~/.config/MySoftware/1.2.3 symlink with chezmoi.

VorpalBlade commented 2 years ago

Symlink would be fine except during upgrades. During upgrades, at least SmartGit doesn't move or copy things. It writes a whole new directory with whole new files. As long as I notice that I can handle that manually. So for smartgit, which I install by deb or AUR (depending on system) it would be fine, as I would notice the update.

For PyCharm, which I install as a snap on Ubuntu with auto updates, that might be a bit annoying. But I could write a script that detects the new version directory exists and informs me (or even takes automatic action) I guess.

twpayne commented 2 years ago

A few random thoughts:

  1. As you say, chezmoi's "escape hatch" for handling things that don't fit chezmoi's declarative approach are run_ scripts, and they seem appropriate here.
  2. Once good practices for handling tricky situations are developed, tried, and tested, I'm very happy to add native support to chezmoi for them. Externals are a good example of this.
  3. As the applications in question are closed source (meaning you can't submit a PR to improve things), commercial (meaning they have a responsibility to their paying users), and not following the conventions for configuration files, I would argue that the burden for fixing this lies with the software provider, not chezmoi.
twpayne commented 2 years ago

Closing this as the burden is on the non-conventional software to follow convention, and there's no clear algorithm for chezmoi to follow to work around the non-conventional software's peculiarities. Please re-open if needed.