I like to store all KiCad configuration files inside of each project directory instead of storing the configuration in my home directory. That way I can keep the configuration under version control and have independent configurations for each project instead of sharing one configuration between all projects. When I start working on a particular project, I point KiCad to that project’s configuration using the KICAD_CONFIG_HOME environment variable. This works well, except for a few issues.
I would like to be able to clone my KiCad project repository and have the KiCad configuration work on any machine, independent of information like my user name. The configuration gets broken by issues like storing absolute paths in the configuration files.
Is there a way to tell KiCad to store relative paths rather than absolute paths in the configuration files? Or can an environment variable be used to replace the absolute portions of the file paths? I do not want want information like my home directory named saved in my project repository.
Right now I work around this by manually deleting all of the absolute paths from my configuration files before committing them to version control. Or I use the skip worktree feature of git to prevent any configuration file changes from being committed. These are both tedious since I want most configuration file changes to be committed, just not information that will break my configuration on other machines with different file system layouts and such.
Does anyone else save their configuration files locally in each project? If so, how do you work around these sorts of issues? Thanks!
Why do you want this? What specific configuration options do you want to have be per-project?
The configuration files in KICAD_CONFIG_HOME are supposed to be machine-specific, not project-specific and not shared between computers. It would be better in the long run to make feature requests about the specific things you’d like to achieve rather than this particular workflow you’re trying to use to achieve those goals.
Sorry to hijack the thread, but it was close enough so I could chime-in:
I’d like to have Per-project BOM command lines, so they could better match my project’s individual variants.
Now they all live in global “eeschema.json” config file.
Specifically what I am trying to achieve is a reproducible development environment for every KiCad project.
I have changed the name of this thread from “Issues storing KiCad config files inside a project directory” to “Reproducible KiCad development environment for every KiCad project” to reflect that.
I want to be able to work on a KiCad project on different machines and I want to be able to open a KiCad project years after creating it with the exact same KiCad version and the same KiCad configuration as when I created it. I would like to be able to have all configuration information stored inside of each project without it containing any machine specific information.
I use containers to make reproducible development environments. The container keeps track of the specific KiCad version and the specific versions of all dependencies, such as the KiCad libraries that I use.
I can then run this container and get the exact same development environment on any machine or I can share this container with other people and they can open my project using the exact same version and configuration so all of the colors and sizes and information like that is preserved.
I understand that this is not how most people run KiCad and this will not work on all operating systems, but I find it way easier to work on many projects over many years if I can store all of the information within a project version control repository that I need to perfectly recreate the development environment across machines, between different users, and over time.
I guess, but I do not see the value in it. For me, the important thing is to be able to reproduce the fabrication outputs from a design, not reproduce the whole development environment. If I happened to be using a different color theme 3 years ago, I don’t need or want to recall that color theme when I pick back up that project.
Well, for example, I automatically generate documentation for my project and I like to be able to specify the color theme for the documentation images. If I do not save the color theme, then I may have a difficult time reproducing those documentation images in the future. I consider the documentation part of my fabrication output, but I understand that other people may not feel the same way.
I just think it would be nice to be able to save that configuration information for each project or not, depending on each user’s preference. The configuration files as they are mostly work already. Just having an option to not save machine specific information in the configuration files would really help. That or putting machine specific configuration information into separate files inside the configuration directory so those files could be ignored by the version control software.
My approach would be to find a way to specify a certain color theme in a per-project way when generating these outputs, rather than storing the “display” color theme in the project.
You cannot load a theme from an arbitrary location at the moment, nor can you specify a theme by its elements (e.g. passing in color values on the command line or something)
For me, I would rather just save all the information I need to recreate the entire development environment, just in case I need it later, especially when it is just a few text files. At the very least, that way everything looks the same when I edit my project on another machine. If I pick and choose what I save then I may regret losing some of that information in the future.
I get that other people may not want that. If it is too big or difficult of a change to provide that option then I understand.
If the only issue you are having is absolute path leaking usernames then you can use git clean/smudge filters to obfuscate the username or any other sensitive bits and then restore it back to original when you do a checkout.
Yes I would still prefer that KiCad had the option of saving such machine specific information separately in the configuration files as that would be the cleanest.
Ultimately, though, I just do not want that information committed to the project repository so these git features would work for my needs even if it is more manually intensive for me to have to specify all of the machine specific information in another file so it gets cleaned and smudged properly.
A virtual machine is extreme, but yes that could work, especially if you are running on windows.
Running on GNU/Linux a container is much lighter weight than a virtual machine since it does not need to include the kernel or most of the rest of the operating system.
I try to include the bare minimum number of files inside a container, just enough to fully reproduce the development environment and nothing more. So that would include KiCad and all its dependencies and all of their dependencies recursively. It would also include the project files. I also like to include the KiCad config files, but their necessity seems debatable to others.
That development container can then be run on any GNU/Linux machine or years in the future even if the host operating system massively changes without worrying about compatibility or availability of dependencies.
That development container could also be run on windows or a mac, but yes it would probably need to run inside a virtual machine or on the WSL Linux kernel or a Linux kernel running on a mac.