Is there any specific place in the source code repository where we can have a look at the latest Python API code updates? I’m REALLY looking forward to the new python functionality. Any medium term ETA for any nightly versions we can have a play around with, or any plans for inclusion in any V7 release candidates? Thanks.
Basically it’s not happening.
What about the PCBnew side of python or is that already fully functional? Does the Python API work only apply to EESchema?
I’m sad to be right when I predicted it won’t make it into v7.
OK. Possibly opening a can of worms here (you’ve been warned, whatever I wrote below in this post is my private opinion and it doesn’t reflect in any way the policies of the KiCad Project)…
I’ve designed PCBs (sometimes very complex ones) for my living for years and I never really needed nor used any scripting capabilities in any PCB tools I used. I can only think of two exceptions:
- automatically generating Gerbers/other manufacturing documentation/BOMs.
- exporting a design from a proprietary tool to another tool
So why so many people consider the Python API so urgent and so important? What is KiCad (let’s focus on the upcoming V7) missing that must be done currently with scripts/plugins? If we are missing some important, basic functionality, maybe implementing it directly inside KiCad would be the way to go?
Tom
2 Likes
As I said, I very rarely need plugins, but isn’t equal to “professionals don’t need plugins”. I’d also refrain from judging if Python coders are more or less valuable than C++ coders. What I can say for sure is that creating and maintaining a stable Python API (that will be stable across major releases) is not an easy task and will take some more time.
Do you mean compatibility between KiCad versions of the Python API? If so, this is because we don’t have a stable API right now. The SWIG-based API that exists today is not actually a real API, so we can’t trivially guarantee compatibility. That’s one of the main reasons the new API is being created – so that we have a “real” API that can hide changes to the underlying code.
1 Like
My main reason for being interested in Python scripting is so that the panellising of many boards can be automated. At present, I use the append board function in PCBNew for this. I’m hoping that in the future a script can be created that can do 2d bin packing and can recreate the functionality of a program like GerbMerge from WITHIN KiCad. I understand that the Python API is a major undertaking, and I support all the work that the developers are doing to make this a success. I’m looking forward to this, no matter how long it takes. Thanks.
1 Like
There is already at least one script that does panelization using the current API: GitHub - yaqwsx/KiKit: Automation tools for KiCAD does this not work for your needs?
2 Likes
Why do you need to panelize boards yourself? Most PCB manufacturers do that for you…
We panellize boards from students for production on an LPKF router. So no involvement of a board house.
These boards are different boards and not copies of the same board. I’ve not tried Kikit yet. Does it support the panellisation of different designs on the same panel?
I also use an LPKF router. LPKF’s software supports panelization and has to be used anyway to generate toolpaths, fiducials, cutouts, etc… So what would be the advantage of KiCad’s panelizer over the LPKF one?
I daubt (didnt try) about different board panelization support in kikit. Please upvote this native feature request: Pcbnew: Create panelization tool (lp:#1782927) (#2180) · Issues · KiCad / KiCad Source Code / kicad · GitLab.
I don’t consider new python API to be urgent but it is important.
In general plugin interface significantly lowers entry barrier for someone who wants to extend software functionality. There are many examples of very useful plugins in the plugin manager already, they show that there are things users are interested in that don’t have to be in the kicad source itself and therefore add maintenance burden on the core dev team. Most of them are not things that an average EE needs every day but they save significant amount of time on those occasions when you do need them.
Eeschema is suffering for not having an API, even a swig generated one. You don’t know what things are never built because there is no convenient way to build them. We do know that some existing plugins that use schematic data were slow to update to v6 or never updated to it.
Even project manager could really use a plugin interface. It’s just a launcher, what does it need an API for, you ask? Project archiver plugin for example (it lives in pcbnew now because it’s the only one with plugins even though it actually acts on the whole project). Maybe VCS integration plugin. Maybe database integration. Maybe something else.
In short, having API:
- Opens possibilities and the community has shown that it will make good use of them if they are available.
- Spreads the development workload across many devs vs just the kicad team.
- Decouples some development from kicad’s release cycle, freezes, etc.
8 Likes
In an ideal world the toolsuite does everything that is needed
In practice this isn’t the case and thus an API permit expanding the overall capabilities without the overhead of being incorporated
Sometimes it is development cycle (eg teardrops was done via plugin … Now in nightlies) or concepts that are deemed not needed as core (maybe kibuzzard)
Another point why an API can be interesting is the incorporation/interfacing with procedures etc. outside or involving PCB designs. This is usually something which differs from user to user (and company to company) so this will never be something implemented in the KiCad core, but nevertheless can safe the users a lot of time if some of the procedures can be automated based on the API.
So why so many people consider the Python API so urgent and so important? What is KiCad (let’s focus on the upcoming V7) missing that must be done currently with scripts/plugins?
I don’t consider it urgent but it would be nice. So I’m interested in this issue and ask from time to time.
You are right, the “normal day work” is possible without scripting. And normally all work can be done with the core program. But the scripting allows additionally flexibility for tasks which are user-dependant, so the scripting could give a solution for special users while at the same time doesn’t clutter the kicad-UI (with seldem used functions).
If a API for pcb+schematic is released I have the following function on the slip:
- finding datasheet not with exact datasheet-link, but based on symbol-name/value-name.
- BOM-generator with access to both schematic+board. Currently bom-generators run from schematic don’t have access to footprint-fields. And bom-generators run from pcb miss symbols with “don’t add to pcb”-attribute set.
- overview-dialog with all custom textstrings on the board. On crowded boards this really helps to identify not updated data (filename/date/version/changed connector-description/whatever). This last point could be obsolet with the new search pane.
Generally I like the idea to put seldom used functions into external scripts: it allows users to work with these functions without messing up the GUI for all normal/simple users who only use the basic functionality.
1 Like
A thousand “I wish KiCad had this feature” requests could be addressed by an API while the KiCad devs focus on continuing to make KiCad a great core product.
We’ve been told on more than one occasion that feature X people want isn’t going to happen due to the necessary labor to add it and maintenance effort to keep it updated and that people should write plugins if they want those things that fall outside the scope of the EDA core.
KiCad is spectacular but it’s still an OSS volunteer project. There’s no denying there’s still a feature gap compared to other EDA software. The quickest way for KiCad to “punch above its weight” is to open up development to more people who can’t or prefer not to learn the entire Git/building/compiling/C++ pipeline (if their feature is even accepted) just to add something that could be a 50 line Python script.
And frankly I can’t imagine assembling a prototype without the Interactive HTML BOM. Also KiBuzzard and the JLC and PCBWay assembly plugins are just tremendous.
3 Likes
A thousand “I wish KiCad had this feature” requests could be addressed by an API while the KiCad devs focus on continuing to make KiCad a great core product.
We’ve been told on more than one occasion that feature X people want isn’t going to happen due to the necessary labor to add it and maintenance effort to keep it updated and that people should write plugins if they want those things that fall outside the scope of the EDA core.
This.
Having API would allow to grow a vivid ecosystem around KiCAD. We could also quickly test new features (e.g., assisted bus routing? Generating fanout? Annotating schematics with datasheets, generating schematics), integrate KiCAD with 3rd party tools (e.g., CAD), and automatic manufacturing data. All this with minimal effort from the core team.
It would also allow us to quickly test ideas and find ways to do things.
Yes, I can fork KiCAD and implement the functionality (as C++ is my primary language), but I have no sane way of distributing my modification of KiCAD to users and also, my changes are incompatible with changes from others. Without users, there’s no testing and we have no clue which ideas are good and which are bad. Having plugins solves this problem.
PS: If there is too much burden with designing a stable API, I think the community would appreciate having “near complete” SWIG export. We can work with unstable API, we can build abstraction layers. But we need something to build upon. (original proposal with discussion Feature proposal: Export all the KiCAD internals to the Python API and let the community build stable API (#7134) · Issues · KiCad / KiCad Source Code / kicad · GitLab)
1 Like