SAVE_CONFIG in separated file

Features
1

I don’t like so much how SAVE_CONFIG handles my printer.cfg file, commenting overrode properties, and appending a magic commented block with a magic header.

Additionally, there is a “feature” that only allows you to override a config property only if it’s defined directly in the config.cfg file, but not in an include.

I think, a much simplier approach, would be to store that overrode config in a separated file, with the same syntax as original. The file could be named printer.override.cfg (like Docker does with docker-compose.yml and docker-compose.override.cfg files), or similar.

That new file could have a header, warning users that it’s autogenerated and shouldn’t be manually modified.

Load config process would be done in 2 steps:

  1. Load config from printer.cfg file.
  2. Override properties from printer.override.cfg file, if present.

Save config process would simply create or recreate the printer.override.cfg file with the new values.

I understand that it could create confusion with some users, looking at config in printer.cfg, and thinking that a parameter is configured to some value, but the current value is different beacuse is overrode in another file; but I think it could be “easily” managed in the frontend’s editor.

This approach would allow to override config defined in included files, and to ignore the automated changes if you don’t want to store them in a repository. I think it could also simply the config parsing, as no magic block are involved.

What do you think?

2

I’m not sure how much of a problem this is or exactly what you are concerned about.

After doing an operation that has the system provide an updated value (ie PID or Probe Calibrate) the SAVE_CONFIG only comments out the original values that were there and then puts the new values into the SAVE CONFIG section of printer.cfg.

If you like the values that you had originally, then you don’t do the automatic operations that require you to do a SAVE CONFIG or you simply don’t do a SAVE CONFIG and manually record the values and enter them into you printer.cfg.

I don’t see a lot of “magic” in the process and it was pretty clear to me what was happening, right from the very start. It was pretty obvious to me that the changes were generated by the system and the line:

#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.

is pretty self-explanatory.

Maybe you could better explain exactly what the issue is for you and why adding complexity to the process is warranted.

2 Likes
3

Your Klipper host is running Linux.

Have you thought about a shell script doing that?

There should be a way to automate that.

Please give more input about your setup. Mainsail, Fluidd?

4

My problem with SAVE_CONFIG is that its functionally is incomplete, and the implementation is a bit odd.

The config does support to be defined in serveral included files; but SAVE_CONFIG doesn’t, It only works for config parameters in the main file (printer.cfg). That’s why its functionality is incomplete.

Config files are user defined files, but SAVE_CONFIG transforms them into a mix of half user, half system, defined files.

I can understand SAVE_CONFIG in two ways:

  1. An “automated copy/paste” that helps users to persists config changes to theirs files.
  2. A system to override user defined configuration.

As an automated copy/paste, it should just modify the property’s values in place, that is, edit the config files as the user would.

As a config override system it should not mess with user defined files.

How does it currently work? Well, a mix of both. It comments the original user properties, and appends them again at the end of the file, but in a “magic comment that is not really a comment”. And that’s why I think the implementation it’s a bit odd.

I found the automated copy/paste approach more “natural” for the user, but more tricky to implement (file permissions, versioned files from third parties, backup of multiple files, atomicity, …).

The config override system just needs to write a file, and read it on boot.

With this approach an user could clone printer_data/config from a third party repository, and its own overrode config would be stored in a sepated file, that could be ignored in the CVS.

That’s why I find this config override system easier, and more versatile.

1 Like
5

It would be easy to create a shell script that calls inotifywait to look for config changes and processes them, and register it as a system.d service, but I find it unnecesary.

I feel like SAVE_CONFIG could be improved to be more useful.

6

IMO, it is neither of these.
It is a method to put system generated values in the cfg and makes sure that these are:

  • separated from the user generated / default ones
  • separated from values the user would modify
  • make it transparent / evident to the users that there is a difference between user generated and system generated (in the sense of “better don’t touch it”)

Since there are so many interesting things that could be extended or improved in Klipper, this topic falls into the “I must be severely bored” category - at least in my opinion.

4 Likes
7

Hi @Sineos, you just described a config override system, and emphasized in “separated”. Mixed in the same file is “separated”, but not much.

There are also many ways to say things, and you response falls into the “not very polite” category.

Thanks anyway for your help, and sorry for wasting your time.

8

I think what he meant was that there are a lot of big plans for growing and extending Klipper in terms of functionality, so no developer is likely to spend time on reworking how the config files work unless and until there’s no other work to be done so they’re bored and looking for something to do. This is why @mykepredko asked “why adding complexity to the process is warranted.” Unless a requested feature is going to make a significant improvement for a significant number of users, it’s simply not going to get much traction.

9

You keep saying “overrode”, the only thing that is in the SAVE_CONFIG portion is changes YOU made via GCode or the UI. It’s a helpful way to save changes that you’ve stated you want to make to tweak things that are more variable (Z height offset, PID tuning etc).

I’m not sure I totally understand the concern here, your wording makes it seem like the system is doing something you don’t want it to. But again, SAVE_CONFIG is things that you’ve specified you wanted. If you don’t like those changes, you can just change them and run SAVE_CONFIG again or you can remove them from your printer.cfg

It uses printer.cfg becuse the system is sure that’s a file that you will have, it’s the default necessary file for Klipper to run. I’m not sure why you’d want to introduce ANOTHER file to dig through for changes. Especially since the SAVE_CONFIG section is relatively short.

1 Like