Here is what I learned about the current state of the Python API while writing an ActionPlugin for generating all of our required documents for a PCB revision:
Gerber, drill, DRC
Works fine with Python API besides some known issues like 11562
Component placement .pos
No Python API for having the KiCad report created, no command line interface (CLI).
The format of the pos file can be reverse engineered and created with the raw information in Python but updates/fixes will be missed.
schema.pdf
No Python API for eeschema, also no CLI
BOM
No Python API, no CLI
A BOM.xml can be created manually with e.g. kicad_netlist_reader and then converted into the preferred format in Python.
KiKit reads directly eeschema_v6 for the BOM, but that approach will miss changes in file format.
Development
I edited the code in Documents\KiCad\6.0\scripting\plugins\MyPlugin\ . When KiCad could not load the plugin due to code errors, I could not find the log/information for the cause even though it seems to exists?
A manager like 2475 would be nice but I definitely prefer a clean Python interface.
Python scripting for the Schematic Editor has been planned for quite some time, and it’s being worked on, but development took too long for KiCad V6, and therefore it has been pushed further into the future.
Requests for a command line interface is also an issue on gitlab that has been open for a few years…
There is no lack of ideas for improvement, but only a shortage of developer manpower and hours.
And though remarkable progress is being made (and it’s accelerating) (some 5 to 10 issues are closed every day), the total number of open issues on gitlab is still growing and it recently increased to over 1500.
If there are open issues on Issues · KiCad / KiCad Source Code / kicad · GitLab that are important for you, then give them an extra on gitlab to give them some more weight, but please do not add comments just for bumping an issue, because this only wastes the time of the developers reading those issues, and that scarce resource is put to better use when those people are actually writing code for KiCad
Every KiCad user needs to generate documentation and those going for quality will investigate in an automated process. Maybe some of those people can save some of the considerable time it took me to figure out the current state of “generating documentation with Python API”. That’s the intention of posting it here.
Having open feature requests is totally normal and will endure as long as the project is healthy. It’s great when you know all those open feature requests and even better, invest your time to help out here in the forum. I cannot get involved that deeply in KiCad and I suspect many others cannot either. I hope this summary can help those people.
KiBot is a fantastic project with great code quality. In fact, I learned a lot from the code in KiBot. For example, I thought about using out_position.py, it even has some test coverage.The main reason I still generate the .pos file manually in KiCad is that KiBot needs to copy the format of the KiCad .pos. That means it can differ in subtle ways and porting future fixes/updates in KiCad takes time. That’s not great when the main driver for automation is quality assurance.
on gitlab to give them some more weight, but please do not add comments just for bumping an issue, because this only wastes the time of the developers reading those issues, and that scarce resource is put to better use when those people are actually writing code for KiCad 