kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

Hi Greg- 

Thanks for reaching out.  We'd love to involve more Python developers in
the KiCad development.  We haven't had anyone really stepping up to fix
the existing scripts (footprint generation notably) or expand them. 
This would be the logical place for a new KiCad developer interested in
Python to begin working. 

The development of the API is a critical path item for us in v6.  We are
building the Eeschema API and unifying it with the Pcbnew API. 
Currently, the SWIG interface is untenable and will be deprecated in v6
and removed in v7.  It is large and unwieldy, requires a long recompile
for every minor change and is, by definition, fragile.  

Our plan for v6 is to move most of the python API over to the tool
interface.  All elements in the API will be opaque, meaning that Python
will not see any of the data structures.  It will have getters/setters
for parameters that have a thin C++ layer to maintain naming convention
and functionality.  The C++ layer will have a SWIG interface for Python.
 If we have a python developer committed to taking on a maintaining a
Python layer instead of the C++ layer, then we can discuss the idea of
using a Python wrapper instead.  But right now we don't have that
expertise on the lead dev team. 

Best-
Seth

KiCad Services Corporation 

 		Seth Hillbrand

 		LEAD DEVELOPER

 		+1-530-302-5483‬ [2]

 		Davis, CA

 		www.kipro-pcb.com [3]    info@xxxxxxxxxxxxx

 		https://twitter.com/KiProEDA [4]
 		https://www.linkedin.com/company/kicad [5]

On 2020-06-28 09:51, Greg Smith wrote:

> I started a discussion on the forums 
> https://forum.kicad.info/t/python-api-development-discussion/ [1] 
> and it was suggested I post here. 
> 
> There has been discussion here and on the forums about "standardizing" the Python API. Making it more stable through releases. I have been developing Python plugins (like KiCommand) since 2017, and have some ideas. Please consider this a community discussion on ways to stabilize the Python API. 
> 
> The primary method put forward by developers is to code the API in the KiCAD source code in C. 
> 
> I think the better way to involve more developers and decrease the burden on C core developers is to continue with the SWiG API for the core KiCAD classes and methods, and to add a Python sliver layer that implements a stable Python API. This could increase the developer contribution to those primarily contributing in Python (like myself). 
> 
> I have spent many hundreds of hours converting the current SWiG API into a command-line suitable API and I think it has worked out fairly well. There have been many small changes to the current SWiG API as a result of source code changes, but they have been relatively minor since early 4.0 releases and the changes required in Python have been easily fixable. 
> 
> More important for developers, I think, is to keep pushing forward in making more capability available instead of trying to maintain backward compatibility. 
> 
> My hope is that this frees up the KiCAD source code developers to add things like GUI control and access to eeschema, the footprint and symbol editors. 
> 
> Core KiCAD developers, or suitable Python developers could then maintain the Python sliver (wrapper) for backward compatibility, and the Python API could then have incremental improvements and compatibility-breaking changes on a schedule that is different or slower than the SWiG API, which changes with the source code as needed. 
> 
> Thoughts? 
> Greg S. 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
 

Links:
------
[1] https://forum.kicad.info/t/python-api-development-discussion/23604
[2] tel:+12126039372
[3] https://www.kipro-pcb.com/
[4] https://twitter.com/KiProEDA
[5] https://www.linkedin.com/company/kicad