Archive_project plugin - unarchiver?

I need to archive a project so that it is portable and can be worked on by a team located elsewhere. I don’t see a way to do this.

  1. The “archive all project files” button does archive the project. However, when I send the resulting zip file to a distant machine, the file when unarchived doesn’t work unless the distant machine has the symbols and footprints in the same places. This means that the distant machine must be a clone of mine. This situation is awkward to maintain.

  2. If I use MitjaN’s “archive_project” action plugin, I get the -archive.lib file in which all of the symbols used in the design can be found, however, this is also a little awkward to use also because all symbols are in the “archive” library. I haven’t tried adding a symbol to this library but to do so seems counterintuitive.

My ideal solution would be MitjaN’s action plugin with another unarchiver action plugin which would allow the user to ask the user to which folder the unarchived symbol should be placed. That would speed the process of transferring a project to a distant site while setting up the machine at that site so that the distant team could make changes to the design.

Is there currently any way to do this?

Also, could I ask that one of the “archive” button or the “archive_project” action plugins have a name change? Perhaps the action plugin could become “Make project portable”? They work very differently from what I can see and having names so similar make it very confusing to the user.

Thanks, and
Best regards.


My ideal solution is to have the

Thanks for the feedback.

The plugin is not really usable for collaboration on a project, as you’ve found out. The main goal of the plugin was to archive the project once the PCB went into fabrication, so that all of the assets for the project are contained within the project folder. Thus any changes to the libraries from that point onward do not affect the project.

What I’ve found out was that the easiest setup for collaboration is to use common (shared or global) libraries only. No project specific libraries. No user specific libraries. Any asset that is used in the project and exists only in user or project specific library has to be put in the common (shared or global) library and used from there. Here git is really a must.

We base our libraries on KiCad official libraries, but we have our own copy (private repo) where we only add assets. We don’t change any assets already in the library. The main benefit of having our own copy of the official repo is that we can add assets which can not be accepted in KiCad repo due to licensing issues (mainly the requirement to not redistribute 3D models).

Once you accept the fact that any collaboration requires meticulous library manegement, life becomes easier. Until then you’ll most likely have issues with differences in the assets (two symbols for the same part created by two different user, a symbol for a part which was modified by one user but not shared through all the libraries, …) And from my experience the library management takes less time than resolving the screw-ups. But there is an initial cost of teaching all the users how to use git for library management.

Now to answer your questions:

The -archive.lib file is project specific library which is referenced by project specific sym-lib-table file.
You can move the -archive.lib file anywhere you want but you’ll have to change the path within sym-lib-table. I can only see this working if you would want to put the -archive.lib file into a specific subfolder within the project folder. I strongly advise putting it anywhere else.

As for the “unarchiver”. It is doable, but as I am short on time and as I personally would not use such a tool I will not be the one implementing it. I do hope you understand this. If I would do it though, I’d firstly have to think whether I’d want this as a stand-alone tool or as an action plugin. I’d probably go for standalone tool and I’d reimplement the archive part also. I’d base it on python (KiCad’s) use tkinter for GUI and reuse the business end of my plugin. I’d just add one final step where I’d zip all relevant files into .kicad_project_zip file. The “unarchiver” would take only files with this extension and would unzip the project and move the -archive.lib file and remap the path in project sym-lib-table

Thanks for the hint. I agree I’ve chosen a bad name and I am sorry for it. I’ll correct this but only for V6 compatible version of the plugin (link to the github issue).

There is some helpful advice and a few hints in the FAQ about shared assets and how to manage them.Worth a read.

I do not understand what would be the problem with project specific libraries, or even why there would be any problem at all with them.

I have some interest in MitjaN’s scripts, but have not used them yet, but am interested in having projects not relying on external libraries, and Irecently did it the “hard” way.

Pcbnew / File / Archive Footprints / Create new Lib and Archive
It asks for a libary name / location, and I made a project specific library, and I think KiCad made the link for me, but it’s in:
Pcbnew / Preferences / Manage Footprint Libraries / Project Specic Libraries, and there it’s relative to the project:

If I remember well , it just exports all footprints from Pcbnew, but does not use that backup as the real thing. For that I opened the schematic file in a text editor and with a bit of search and replace updated all Footprint links to point to that project specific library. Then Save, exit text editor and start KiCad / Eeschema and then [F8] to Pcbnew to update the footprint links there also.

For the EEschema symols I did someting similar. I forgot how I did it exactly, but I think I removed the “-cache"" from the cache lib, and moved it to the ".pretty/” directory, opened the schematic in a text editor and a bit of search & replace magic. Or I did it with:
Eeschema / Tools / Edit Symbol Library References

The result is that all the symbols used in the schematic are in a project specific library, and as the “.pretty” directory already existed for the footprints, I also put the library ( 2 files, not each symbol separately as with the *.kicad_mod files.)

After this, there should be no more dependency of external libraries and the whole project directory should be able to be zipped and put on another PC with a KiCad version with different library setup or whatever and still work as normally, (with the disturbing question mark symbols in Eeschema).
Then in Eeschema you can verify it worked by:
Eeschema / Tools / Edit Symbol Fields
At the moment is was a manual task, party for me to learn how KiCad’s library structure works. I think MitjaN’s scripts automate most of this.
Wen working on a project, you of course add new symbols (from other libraries) which you then also have to manage manually, which is another reason to look more into scripting.

As i detail in my FAQ there are different workflows for different requirements. Everything in live is a tradeoff. In this case it is scalability and accountability vs share-ability.

A central lib is simply the way to go for multiple people working together on multiple projects (for example within a company). As this allows the central lib to be vetted and there is only one place to find assets.
Having local libs would mean you need to possibly search through multiple projects to find the library asset you are after. And there is always the danger of redoing existing assets because you do not know they already existed or to take one that was wrong because you found it in the wrong project (the one that never got made).

If you work alone then i would also say a central lib is the way to go. As this means your assets are easily searchable.

Fully decentralized libs are a perfect option for people who make mostly open hardware projects for sharing as you then want your users and contributors to be able to easily open the project without any need for prior setup.

And then there are in between options. Which is where the archive project plugin really comes in handy.


I’m quite aware of the pro’s and cons of these workflows, just did not realize in time which workflow as applicable here.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.