Moving from Python to Lisp/Lua

Community Feature Request Chat
53

Wow, that’s based on Debian hasn’t even made a decision on dropping support for Python2? Ubuntu is doing their own job on this.

54
55

Short status update:

8 Likes
56

My takeaway from the article :

Debian has made the decision to ship Python 2 with Debian 10 (“buster”), which will be released in mid-2019; that means Python 2 will be supported in Debian well past its 2020 end of life. For Ubuntu, the plan for the 20.04 LTS release has Python 2 removed from the main repository. That means it will not be supported by Canonical, so the community will need to pick it up if it is to continue at that point.

Historically, KiCad devs would wait until KiCad no longer builds on several platforms before updating a dependency, I think we can see with gtk3 this causes a somewhat painful experience. The trade off is causing users a lot of upgrading work.

So there is a non-obvious “right time” to move to Py3, my gut tells me between now and v6 release is the time. It might be nice if KiCad was ahead of the curve on this one, even though I am loathe to rewrite a lot of scripts for Py3, it has to be done sometime.

A clear heads up for users is needed, KiCad should announce that v6 will have Py3 support and you have all got 2+ years to get ready. Nightlies post 5.1 should have Py3 enabled by default.

7 Likes
57

This is great
It’s important to get real information on what works, and what does not, and to confirm what is possible.
Can you expand on what
I already ported some scripts and they are all working.
vs
Scripting inside of KiCad was not tested yet.
means ?
Does the first one mean you can access Pcbnew database from Python3, (via import pcbnew ?), or something else ?
For the scripts that are working, can you broadly list what they do/use, perhaps in a ‘tested so far’ read me portion on github ?

58

Clearly Linux is not going to be a problem except for wxPython.

As Wayne points out on Launchpad, Windows and mingw32/64 is the challenge.

59

FWIW, I started to port my personal scripts (not KiCAD related) to py3 a year ago and should have converted all systems I administer to py3 within another 12 months.

1 Like
60

Ok, In more details what I have tested/ported so far successfully:

What is not tested/ported:

  • footprint wizard. I suspect there is a strong dependency on wxPython because it is not available inside of pcbnew on my system
  • more complex action plugins.

If anyone wants to try the python3 branch add -DKICAD_SCRIPTING_PYTHON3=ON to the cmake flags.

5 Likes
61

That’s great, sounds like very good progress.

Other simple scripts you may like to test are ones like

and this one is a plugin, more integrated, to a running PcbNew …


62

Its hard to maintain everything for developer, but you can though also get the query to be fulfilled by any of python or odoo development services provider.

63

I think simple interface in native python class to encapsulate C++ API function call would do. It also allow the maximum flexibility for backward, and forward compatible event C++ API function change so much. Allow a freedom on C++ API function call interface refactor without broken old python scripts if their always a set python codes can be make for old python interface classes work in similar manner. This way, also all other script languages added more easier too by addition native interface of it’s own.
And a C++ API direct function call should be enough for all other script language interface class to work.

1 Like
64

I managed to get the wxpython-4.0 patch of @mmccoo working and ported it to be in mergable state. Now I have Python 3 with the new wx binding running:

kicad_wx_phoenix
kicad_wx_phoenix1184×649 90.5 KB

The code can be found in a new wx-python branch which is on top of the python3 branch. Please read the commit message carefully, otherwise it will not compile due to a missing include of the Phoenix binding. It can be activated using -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON

13 Likes
65

I think you are getting the abstraction layer interface right and the wxPython 4.0 update you have done was another missing chunk. IMHO we should consider merging your changes in 5.1. Thank you pointhi, you have done very valuable work!

7 Likes
66

The Footprint Wizard is now also running. I managed to get it running with wx3.1 and gtk3 on Linux (some other config variants caused gui issues).

Thanks to @nickoe we also have a working windows build now: https://jenkins.simonrichter.eu:8443/job/windows-kicad-msys2-patch/89/

4 Likes
67

Very cool to see this getting done quickly! Most distros are moving forward with having GTK3 I guess the issue would be LTS distros.

68

Any idea approximate number of months we are from the semi-stable 5.1 binaries? Would love to use mmccoo’s stuff on Windows but haven’t had any luck getting it working just yet.

69

5.1 will mostly fix problems on linux. Not really on windows as the wx stuff still exists compiled against gtk2 for it. (A lot of linux distros dropped support for that old library. Some parts of the python interface rely on that. Kicad now has now only very limited support for python on that distro.)
I think you should open a separate post detailing your problems with python under windows. Maybe somebody can help you with that.

70

I’d love to get the plugins working on Linux too. I tried to setup a virtual box with the plugins running on a Mint installation but it crashes on launch of PCBNew if mmccoo’s plugins exist in ~/.kicad_plugins. So far I’ve only had success on mac with that plugin set.

71

Dealing with recent stability issues in Kicad/python

kicad/python is not compatible with ubuntu 18 (and variants like mint). This is because of the wxPython, wxWidget, gtk2/3 stuff that’s been mentioned in this thread an others. Having my plugins present causes seg faults/crashes kicad on start because I import the wx library. That’s due to version mismatch type issues that probably should have also appeared on older versions but somehow didn’t

Ubuntu 16.04 with the nightly kicad install is probably your most trouble-free bet.

It includes the scripting window and runs python scripts (I can only speak for mine)

mmccoo’s opinions on dealing with overall stability issues, language and all that

I learned python only because that’s what pcbnew supports. Before then I spent many years on perl, tcl, c++, scheme, skill,… Never got paid to write python. Language doesn’t really matter. Pick one and move on, especially now that python support is there. Python is nice because it has so many useful libraries. I resisted python before, cause I love me my curly braces.

Beyond language choice, kicad suffers from two problems:

  1. pcbnew’s c++ data model kinda sucks. No consistency between types (ie, getName has different names between the types). The Kicad developers don’t seem to have a problem with this. Don’t ask me how. Probably cause they’re in close contact with each other and know what’s changing. Since the data model is not that great, the resistance to changing it is small. These changes are then reflected in python.
  2. kicad doesn’t have any regressions that I’m aware of. There are one or two trivial “tests”, but they do little. If I’m misspeaking, please correct me.

Should there be an abstraction layer?
Perhaps, but I think it’d be a shame. I’d be more inclined to change the c++ model to be better. To add another numbered list (I do those a lot), there are two benefits in an abstraction layer that would be important to me:

  1. Can you find what you need? Many object types have names. There should be a common method name to access that name. Today, we have getNetName(), getReference(), getName()… To get from one type to another, should be as easy as get_TheOtherTypeName(). With such consistency, my tutorial posts would be much less necessary.
  2. Once you’ve found what you need, can you rely on it? If the time has been spent establishing some consistency, I’d hope that effort would be honored. Regression tests to enforce would go a long way.

Perhaps, next to the existing sucky c++ method names, I and others can give parallel ones that suck less.

Thanks to those that have complimented my plugins.

I’m glad that others find them to be of value and that they are referred to. I do kicad stuff in spurts every couple months and I enjoy doing it.
If anyone has requests, message me. I do this largely for the enjoyment I get out of programming. If you want/need more direct support I might do that to. My current rate is: “one of whatever it is you’re making” :slight_smile:

1 Like
72

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