There was some talk that *-lib-table files could be nested. This would play nicely as one user would have top *-lib-table (the one in the kicad config folder) pointing to different *-lib-table files each for separate library (kicad official, common library for department, personal, …). So when you update the library, its *-lib-table file is also update and the user sees this changes without modifying user kicad configuration.
But I don’t know whether this is actually in the plan and if it is, when will be implemented.
I think that Krotow’s issue is that he wants a team of designers to share team’s libraries where each team member has access to KiCad’s official libraries, common team libraries and team member personal libraries. And when there is a change in common team libraries where a library entry is added (or removed) such as added or removed .kicad_sym file or added or removed .pretty folder, this changes are reflected automatically in the *-lib-table file with addition/removal of the library (file or folder)
Correct. We are 2 people who work with KiCad based schematics on permanent basis. Also few others and some customers with whom we share the schematics who connect when needed. There are libraries used by everyone and libraries used for particular customer projects. In this situation is nice to have project library separation (note that same libraries may be used in several projects) where common library and customer separate libraries are kept in different Git repositories. With nested configuration that require to be configured only once, keeping local user libraries (added by plugins when experimenting with something for example) out of customer library set, but still available for user who added them. I believe that I’m not the only one here with similar problem
If it were my ‘team’ I would just start from making together with all of them a library lists that will not be extended ever (lists, not contents).
Working with Protel 3 (1997-2017) we (3 people, but only one using Protel at one time) had 5 symbol libraries and 1 footprint library. Only 5 symbol libraries as when you selected symbol for schematic a window to select library had fixed size and without scrolling the list you could select from 5 positions. Only one footprint library - just grew, grew and you never had time to do something with it. But you use footprint library very rarely (compared to symbol libraries - during designing PCB you don’t use footprint library at all).
When moving in 2017 to KiCad I thought few days and decided how my library lists will look like. During these 7 years I have only once added two new libraries. I think that establishing once and for all a common list of libraries is not beyond the capabilities of a group of people working together.
I think for a situation like yours you need a system where the *-lib-table files are generated from other configuration files, one of which is the static (for that major release) list of standard libraries. Unfortunately this means you have to devise your own library configuration system and not use KiCad’s Manage * Libraries actions.
Maybe you can use Git actions to rebuild the individual table files, dunno.
The global library synchronization that would really work, should merge together:
Default KiCad libraries, installed and updated by automatic system update routines.
3d party libraries, added by plugins or users.
Other libraries that was added manually later and defined in “Configure Paths” and under “Manage Symbol/Footprint Libraries”. Mentioned project group libraries fall under these.
The same synchronization must provide possibilities to:
Export libraries and library groups together with their definition names and tree structure to a defined directory or archive file (ZIP, TAR.GZ, etc.).
Import libraries and library groups together with their definition names and tree structure from defined directory or archive file.
Provide semi automatic conflict resolving for existing library entities (symbols, footprints, templates, 3D models) by giving to user the proper resolving choice. Like overwrite or skip overwriting for particular entities and entity groups. In past I noticed few awesome examples in other programs (not exactly PCB/EE oriented) where such actions was done by a tree list with checkboxes for single entities or entity groups.
@craftyjon You can take this post as reference for future improvements. Or I can open a new issue if needed.
We don’t use forum threads to track feature requests, so please open an issue or comment on an existing one if you want to make a feature request.
We don’t plan to implement it as merging together the default libraries with the ones added by users into one file. We want to make it so that users can’t edit the default library table that comes with the standard libraries, but instead can include this default table in their own (editable) table.
@Krotow : If you open / reference some feature request, please tell me which one so I can upvote.
I struggle with very similar issues like the ones you describe
Of course I don’t mean literal preinstalled (default) library in system directories merging with ones added later. Default libraries are stored in protected directory by reason. Mentioned synchronization must manipulate only with libraries added later in user directories (I gave an example above how we are doing it) and merge these with library configuration tables.
I’m now reporting the problem in KiCad issue tracker at GitLab.
The existing issue is for library table chaining, which will fix the problem of having to re-add custom global libraries every major KiCad release. However this issue does not address any requested features related to merging library tables, resolving conflicts, etc. We also have no current plans to implement “import libraries from a defined directory”. Those would have to be a separate request.
Didn’t seen this It would solve my problem. Though it was posted 4 years ago, with that pace I will write some library synchronization script for us faster. But hope that KiCad devs will do something faster than me. Fingers crossed.
