RFC: Provide alternative, symlink-safe, SAVE_CONFIG backup flow

Features
1

Hi All!

Just built my first Voron 2.4 and am having a lot of fun playing around with Klipper. Thank you for the cool project!

I manage all my linux dotfiles using GNU’s stow symlink manager, because it allows me to easily track config files that are spread all over my system in a centralized git repository, with stow handling the symlink creation from this repo to the actual location.

This currently does not work nicely, since klipper’s “Rename then create new config file” flow for SAVE_CONFIG breaks the symlink. See here:

I agree that this is the correct default behavior, but wondering if there was any interest in a config option that changes this to a symlink-friendly but somewhat less safe flow (Create backup file, copy content of original config file into new backup file, modify original config file).

I had a quick look through the code, and this seems fairly straight forward to implement. If this is something you could imagine up-streaming, I would be happy to do the work - just thought I would ask before going through the effort.

In that case, do you have any suggestions where such a setting should be set/configured? printer.cfg? Somewhere else?

2

In that case, do you have any suggestions where such a setting should be set/configured? printer.cfg? Somewhere else?

Looking at the code again, I assume that this should be a start_arg

3

My view:

  • Managing and handling configurations depends a lot on personal preferences, and there are countless ways to do so.
  • Dotfile managers like stow or yadm are used by only a small minority.

Whether this warrants implementation in Klipper also likely depends on personal views. I personally do not see the need and even less a lager user base.

4

Avoiding feature bloat is fair enough.

However I will add:

Dotfile managers like stow or yadm are used by only a small minority.

Somewhat of a chicken-and-egg situation: If klipper wasn’t directly incompatible with them, maybe more people would opt to use them.

My main motivation is not really managing the single printer.cfg I need for klipper, but rather all the different config files I need on the linux hosts on which I run klipper using one tool, so I can easily deploy it - And klipper is one of the few exceptions of linux-based tools that do not play well with it.

But again - not my call to make. I understand the arguement against feature bloat.

5

just checking in to say that I would also love to have this feature and manage my config with stow.

6

Adding a flag to klipper/klippy/klipper.py:258 main() like -D disable autosave" and then go from there?