Plans for the Python API for Eeschema?


#1

Does anyone now the current plans for the Eeschema Python API implementation?


#2

Far, far away. The current plan is to rewrite EESchema similar to how Pcbnew was redone in the last release cycle. I can’t imagine a python API being implemented until after that is mostly done which will take a long time (pcbnew took a year and a half with the Orson and Tom (CERN) working on it).


#3

Thanks, it confirms my understanding of the current situation.
It’s great Kicad 4 is released and I’m eager to see Eeschema refactored.
So for the time being I’ll be processing .sch files with regexps :slight_smile:


#4

Is schematic file format intended to get changed?


#5

any chance that schematic symbols will move to git soon? I’m fairly satisfied with eeschema as it is - but it would me much more awesome if it has symbols on git just like footprints are now!
cheers!
AW


#6

Yes, the schematic file format will be an s-expression based format just like the PCB file.

Anders - you know, I am not sure if the schematic symbols will be downloaded from github.

They are already on github fwiw. If you want to keep them updated you can clone the repo and use them from that.


#7

Any update with Python api for eeschema? We need to create parametrical schemes and programmatically join them and print


#8

Interesting to revisit this topic since the OP was nearly two years ago. The next major release (v5) will have a new symbol library table, but not new schematic file format. V6 will probably have that, and possibly Python API. Python API is not seem as a primary user interface yet it seems, so may not be a priority. However, KiCad development is based more on developer interest than user demand.

I had hoped for 2 year release cycle on KiCad, we seem to be more on track for 2.5-3 year cycle. So a Python API for eeschema could be 3+ years away. I would plan to develop something outside KiCad, in the long run you might be able to migrate to native KiCad scripts. There are several codebases for parts of KiCad, mainly for footprint and component libraries. I’m not sure if there is code available for processing schematic files, apart from the code I wrote.


#9

@bobc Thanks for your reply.

We want to create a web server from kicad, would it be possible to call KiCad scripts from outside?


#10

FWIW, I’ve written some Haskell code for reading and writing schematic files. (I haven’t released it yet because it’s not quite “done”, but I could make it available if there’s interest.)

However, it just does reading and writing of the files; it doesn’t render schematics or anything like that. And I’m not sure that anyone other than me wants to write code in Haskell. :slight_smile:


#11

There is the eeeshow project (https://neo900.org/stuff/eeshow/) which renders schematics.
There is also this project which is the basis for a visual diffing tool for schematics (https://github.com/jnavila/plotkicadsch) - I am working on a Fossil-scm version.

I


#12

@bobc @ppelleti @John_Pateman Thank you, for your answers and insights.
What we need are:

  1. Create manually electrical schemes
  2. From external programming language (not haskell LOL) change only text on those schemes
  3. Join schemes together by external programming language
  4. Create a docker container from those application, including KiCAD itself

#13

There’s always the option of implementing a Python API yourself! There aren’t that many people developing KiCad - if you have some experience coding then perhaps you could tackle this :slight_smile:


#14

@SchrodingersGat I would be able to find resources to support this API development if we’ll find KiCAD is suited to the needs of our company.

Can we talk about this?


#15

Artem if you’re able and willing then I can put you in touch with someone better suited to discuss this. I’m by no means a lead developer and so I’m not fully aware of the direction that eeschema is heading.

However, if you want I can put you in touch with Wayne or Jean Paul who are the project leaders :slight_smile:


#16

@SchrodingersGat, yes, it would awesome. Thank you.
We simply want to find how can we use KiCAD for our needs. Then help to develop parts which is not yet evolved enough for us (within KiCAD vision main stream).


#17

Yes more complete Python APIs would make it easier to propose using KiCad in my workplace. Without trying to hijack the thread I’d like to be able to have a full workflow in Python that would let me:

  1. Generate a pcb file with components selected and placed with nets assigned via a Python script
  2. Run a script for sorting nets based on rules
  3. Generate the netlist
  4. Generate a schematic file based off the netlist with sensible placement of components (it wouldn’t need to make connections, but grouping by sheet would be nice)
  5. Make any changes needed within KiCad
  6. Route or autoroute pcb accordingly.

I think I have worked out steps 1-3, but the others are the tough part without an Eeschema Python API

It’s a bit of a chicken and egg problem - it’s hard for businesses to switch over til it meets a certain level of function, but it’s hard to reach that level of function without the resources that business could provide. Version 5 is looking closer all the time and I look forward to seeing it released officially soon. Though I imagine that more people will come to KiCad as they disagree with Eagle licencing, and certainly when they get tired of paying the Altium subscription fees too.


#18

I’m wondering what it would take for KiCad to break that chicken/egg problem and get to the next level. Probably some sort of non-profit KiCad Foundation, which could collect donations and fund work packages specified by the KiCad developers group. Clearly someone trusted would be needed to manage the Foundation, and the developers would need to be fully involved as it will impact their activity.

For commercial projects the growth path is well known, but Open Source projects are left to devise their own. There are some organisations like BountySource that are making that easier, for example you can post bounties for issues raised on kicad-library right now https://www.bountysource.com/teams/kicad/issues?tracker_ids=638943. I’m not sure if kicad-source hosted on LaunchPad is supported by Bountysource. BountySource charge a 10% on withdrawn funds, which seems reasonable.

Other methods such as Patreon can be used to sponsor specific developers, I guess there are fees associated with that as well. Of course, direct sponsorship via Paypal is also possible.


#19

There’s an extra level of complexity as there would need to be a way for businesses to contribute funds and still receive tax benefits in various countries. It would be interesting to look at comparative product types in the open source space to investigate how they manage their donations or service packages.

Though KiCad is an old project, it still comes across a bit fragmented. But on the other hand appears ready to start breaking out into a new audience with all the issues that come from an increased user base (increased feature demand, UI/UX changes, etc). Where increased features == Python API similiar to Freecad :slight_smile:


#20

Personally, I think companies should damn well pay taxes, and not avoid/evade them, so I am afraid I have zero sympathy there!