Help wanted understanding plugins and python bindings (as it relates to packaging kicad)

Hi, I maintain the kicad package over at nixpkgs
We’re running into some issues because we don’t know how kicad finds its plugins
or what context is expected by tools using the python bindings.

This is complicated by nix not using an FHS environment to store its packages.

Some more discussion is ongoing here, https://discourse.nixos.org/t/7317

Thanks for any help/clarifications you can offer, Evils.

You might be better off asking on the mailing list. Devs rarely look at the user forum.

KiCad has different types of plugins

  • Eeschema bom plugins, which are really arbitrary scripts, not plugins
  • Footprint wizards
  • Pcbnew action plugins

The latter 2 use python bindings. Only pcbnew has python bindings at this moment. They are exposed as a single python module unsurprisingly named pcbnew which during normal installation on linux is dropped into site-packages or dist-packages of system python. In reality it’s just a dumb wrapper around swig-built c++ library so it is useless without the dynamically linked .so file that is located in the same folder.

I don’t know how nixpkgs works but short story is that you need to provide those two files to whatever python environment you are trying to use if it’s not system python.

4 Likes

thanks for noting the different types of plugins, i’ll try to get one of each for testing

we’ve gotten as far as passing site-packages to python and gotten kikit to work (which as i understand it is just a python script that reuses some kicad functions via those bindings)

since nix isolates the location of the bindings and binaries from the libraries (we’re passing the path to the libraries to kicad via environment variables)
i’m concerned there may be some expectation of having the libraries available to actions taken via the bindings as the environment variables mentioned above are not set when the bindings are used

can you shed any light on plugins that integrate with the GUI?

Kicad comes with some eeschema bom plugins and footprint wizards so you don’t have to look far.

As for pcbnew action plugins here are some complex plugins with GUI:



If you can get these to work pretty much anything will work unless they use non-conventional hacks.
In general GUI integration in plugins is very limited by design. Pcbnew can show a button with icon to invoke the plugin, plugins can read some limited state from pcbnew window via API (things like get selected items) and that’s about it. Most of the functionality of plugins is in reading/modifying the board object via API where GUI is not involved.
Some advanced plugins use tricks to manipulate pcbnew window state directly but for the most part plugins work on a simple scheme: pcbnew calls plugin entry point, plugin reads board, optionally plugin modifies board, plugin finishes execution, pcbnew reflects changes to the board if any.

3 Likes

Remember that wxPython is expected by KiCad. It has been a painful problem for KiCad packaging, although Linux world shouldn’t be affected by the msys package problems. And I don’t know what @evils need to know or how this affect packaging, but if the question is “can you shed any light on plugins that integrate with the GUI”, it’s important to remember that KiCad needs working wxPython if GUI plugins are used. It’s possible to compile KiCad without python and wxPython support, but if I understood correctly, that’s not an option here.

1 Like

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