Versioned config folders

[Nick Østergaard]

As asked from Mark on the developers list:

So with 5.0 approaching theres something of an annoying problem on
windows (that many are complaining about). The install location!
Currently, even though you can install kicad into separate folders if
you wanted to, kicad still tries to write to the same appdata folder!

[...]

https://lists.launchpad.net/kicad-developers/msg36410.html

[Wayne Stambaugh (stambaughw)]

Version 5.1 is in feature freeze. Moving to 6.0.0 milestone.

[Anton (antonpupkov)]

The question is very relevant while the projects are not yet in release.

[Anton (antonpupkov)]

When will Kikad 7, we will write the same? Version 6.1 is in feature freeze. Moving to 7.0.0 milestone.))

[Anton (antonpupkov)]

It will be easier for you to work.

[John Beard (john-j-beard)]

This needs some thought, but it's certainly a very important thing to get sorted before v6 starts writing loads of new stuff to the config.

Questions I have (I'll use Linux-y filepaths, but the same applies to other platforms):

* Do we version the *entire* folder? Or are some settings to be shared?

* What do we call them: For example, we currently use ~/.config/kicad. Do we keep that for legacy (up to 5.1) and start using a new folder, eg, ~/.config/kicad-6.0.0. In this case, we run the risk we ran with tagging 6.0.0 early and the folder is misnamed if we do a 5.2.

GTK+ seems to have separate configs: ~/.config/gtk-2.0 and gtk-3.0. Cura uses subdirs: ~/.con

* Or, do we version the configs according to the config itself (so we incremenv

* When do

[John Beard (john-j-beard)]

ugh, Hit tab and can't edit comments at LP...continuing....

GTK+ seems to have separate configs: ~/.config/gtk-2.0 and gtk-3.0. Cura uses subdirs: ~/.config/cura/3.4 and 3.6.

* Do we version on release or have a "dev" config for the moving target of the nightlies?

Also note, by setting the env var XDG_CONFIG_HOME, at least on Linux, you can already provide as many separate configs as you want.

[Seth Hillbrand (sethh)]

I would advocate allowing this to be set by the packaging. Make it an advanced CMake variable that we pick up. It would default to "kicad" to keep the current setting but could be updated at any point when making a new package.

[Seth Hillbrand (sethh)]

This might mean actually using KICAD_USER_CONFIG_DIR, which right now appears orphaned.

[Wayne Stambaugh (stambaughw)]

There are lots of ways to solve this issue but I don't want to over think it. Keep it as simple as possible to minimize the development effort. I suspect that not many users will run multiple versions although I could be wrong. I would be willing to bet that most users don't want to have to reconfigure all of their existing settings every time they upgrade to the latest version so multiple configs should be optional. I suppose we could copy the latest version of the config folder to the new version but that has some downsides.

I would think using a major version granularity is adequate. I don't know that we have ever changed settings in a stable release series. I'm thinking we should use sub-folders for the per version config just to minimize the cruft in the users ~/.config folder.

[Anton (antonpupkov)]

Probably it happened that some branches of kicad are very stable. Therefore, moving to a new branch, which is not yet stable, it is better to use separate settings from the stable version. If we downloaded, collected and decided to try a new branch, respectively it will differ, on the graphical interface, a configuration (the difference between branches 4 and 5 is especially noticeable). I also noticed that kicad makes changes to the configuration files). Each specific branch can make them differently. If I wanted to change the settings of the program from branch 5, but while I'm working in branch 4, there may be a situation when the branch 4 modet work incorrectly (configuration file they have in common). I think it's easy to change the path from home/user/in the code.config/kicad on home/user/.config/kicad{major_version_milestone} - scripted path

[KiCad Janitor (kicad-janitor)]

Fixed in revision 257d9b5fe9d39df65d8001b18507051de508241e
https://git.launchpad.net/kicad/patch/?id=257d9b5fe9d39df65d8001b18507051de508241e

[Anton (antonpupkov)]

Great!

[Anton (antonpupkov)]

O, cmake -DKICAD_CONFIG_DIR... If i want other dir like default .conig/kicad... the main thing is not to forget if I want to try the latest changes in the branch ...

[Anton (antonpupkov)]

Is it really so difficult to redefine the cime in the cmake config file itself and give it the default value plus the branch number? Do not then go into the code itself, for now. In the downloaded branch there is exactly information about its main number.

[Anton (antonpupkov)]

I think that the variable will be equally valid for all branches ... This is not a solution ...

[Anton (antonpupkov)]

I think that -Dkicad_config_dir sets the same environment variable for all branches.

[John Beard (john-j-beard)]

@Anton - when building multiple branches, it's probably easier to use git worktrees for each branch:

git worktree add ~/some/path other-branch

Then you can have two branches checked out on the same repo at the same time, with independent CMake builds (this is useful for reasons other than the config dir). It also saves massive rebuilds on every single checkout.

@Seth: I think a major version suffix might still be a sensible default to avoid wiping out configs by accident, which is otherwise a silent action. Probably not an issue right now between 5.1 and master, but it could become one later, with the extent of expected changes in v6.

Perhaps:

* 5.1/5.11 nightlies -> keep "kicad", this branch shouldn't receive breaking changes anyway.
* master/nightlies -> "kicad5-dev" (or just "kicad-dev"). Means people can run self-builds or nightlies and packaged 5.1 together and won't collide by default (also will need to duplicate configs, but that can be configured away if needed)
* v6 -> "kicad6" -> on upgrade, older 5.x configs are safe by default. Users will need to copy or migrate configs somehow, or configure from new.

If packagers don't like this, they can use the CMake var to set back to "kicad".

There are cleverer things we could do too, like a config version check that warns before you write a newer, incompatible, config to an older config directory. Avoids "silent killer" config wipeout.

[Anton (antonpupkov)]

as far as I understand, the patch appended gives the cmake command to set the environment variable kicad_config_dir to a path that matches for example the path .config/kicad5. But the variable kicad_config_dir the same for all releases and artists now. So the patch doesn't do anything practical. Despite the fact that line 5 and 6 in separate folders, will still be lining. Really it is very difficult for each branch to make the configuration folder, than to think over the mechanism of check of versions of the vedina configuration directory... This problem can be solved by preprocessor directives

[Seth Hillbrand (sethh)]

@Anton- The patch allows anyone building a KiCad executable to specify the default configuration directory. This allows future packages (or personal builds) to utilize different default configuration directories without interfering with pre-existing configurations.

This is in addition to the existing option of runtime configuration changes by using the environmental variable KICAD_CONFIG_HOME. You can still use this each time you run KiCad to get a different configuration directory.

@John- I agree that a version bump makes sense before the next release (or maybe before an RC). But before we change it, I want to have a "detect/import previous settings" implemented. Otherwise people lose all of their settings immediately upon the change.

[Anton (antonpupkov)]

Okay

[Anton (antonpupkov)]

It remains to be a tester and a developer, then I will definitely not forget anything ... Prescribe the variable kicad_config_dir. When to use the program?