Announcing KiCad Package Installer - kipi

I have published an “easy to use” installer for KiCad data, called kipi (KiCad Package Installer). It should be considered as “alpha test” or experimental status.

kipi is a PyPI package which can be installed using “pip install kipi”. kipi is a command line tool currently.

The model used is based on Arduino packages, although it is similar to many other schemes.

  1. There is a file on the interweb somewhere, which describes a data package.
  2. The user runs kipi, giving the URL of the data package
  3. kipi downloads the package info URL. The URL gives further info about how to get the data, either as a git repository, or via zip files. Each package has a publisher and zip files also have a version, which together identify the package and version.
  4. The zips are unpacked, or a git repo cloned.
  5. Depending on the content type, kipi copies files to appropriate folders, or for footprints and symbols, updates the global lib-tables.
  6. A local config file keeps track of what has been installed and where.

Removing packages is simple, since kipi tracks of what has been installed and where.

Updating is also easy, because kipi remembers the URL of the package. The URL is fetched again to determine if new versions are available (or remote git repo checked). If needed new zips are downloaded, or a git repo is updated.


KiCad must not be running when packages are modified. Some features are not available in KiCad v4. Installing 3dmodels requires the user to configure KiCad with a writable location for KISYS3DMOD.

Current packages

I have created package info files for kicad official footprints, symbols, 3dmodels and templates. I have also created info files for SparkFun, DigiKey and Walter Lain libraries. These can be found at


Can this tool be used to install some specific release of a library or will it install the head of the master branch if it uses a git repo as source.

If it can install a specific release, can it also update the package at a later point?

In the case of a git repo which is cloned locally, it will only use the head of master. For specific x.y.z releases, the expected and preferred method is to download a zip file.

I would rather not support git at all, it’s a huge can of worms! Plus, users may not have it installed. I include it because several content publishers don’t deploy point releases, only provide a git repo, e.g. SparkFun, DigiKey. I can download a zip from github/master, but I use a SHA256 to verify the zip, which is not possible if the zip is generated from master. I also can’t tell if the zip has changed without downloading it, in which case I may as well have cloned the repo.

Downloading a zip is more efficient than cloning a repo, but the repo clone is better for regular updates.

Since git has a lot of powerful features which advanced users might want to use, I don’t really want to expose that via another UI. Mainly the tool is aimed at entry/regular users who want a point release, and periodically want to update to another point release. But there is also the option of getting the “latest”, which is kinda similar to the nightly builds, where you get a random version that is the latest build on the day.

1 Like

I’ve been working on a wiki, I’m still filling out the “content publisher” section and worked examples. kipi seems to be reasonably reliable (at least on my PC :slight_smile: ), and several issues have been resolved. The wiki can be found here

I’ve also created an index of packages that can be installed with kipi, that can be found here :


For the moment, I am publishing package files for selected data on my github repo, ideally those files should be published and hosted by whoever “owns” the content. Perhaps if kipi becomes something widely used then I might ask the library maintainers to host the package files.

To make that task easier, I have a python script which automatically generates the package file from github “releases”. It uses the github API to fetch info about the repo and it’s releases. So a repo owner who already creates github releases as zips, then it’s easy to re-run the script for each new release and commit the new package file.

The script is in In fact it can be used on any github repo, not just ones you own.

I also have a script to create package files just working in local zip files, which can be pushed into a git repo (any git that can host raw files), or any file hosting website that can serve files by http.

Hopefully content publishers can easily integrate kipi package generation as a build step in whatever existing process they use to make releases, and for publishers who don’t currently make releases it’s an easy one liner for them to run before committing to a repo.

1 Like

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