I just installed KiCAD5.1.0 in my stock 64-bit Ubuntu16.04LTS from the js-reynaud/kicad-5.1 Ubuntu ppa. To my great delight, Python scripting is back and the Python console is more sophisticated than in KiCAD4. However, oddly enough I observed that the Python version reported when the scripting environment initialized was 2.7. Isn’t KiCAD5.1 supposed to be running Python3? The “About” information (pasted below) does say that Python3 is off.
I just installed 5.1, so I have not tried Python yet. Here is the “About” information:
Application: kicad
Version: 5.1.0-060a0da~80~ubuntu16.04.1, release build
Libraries:
wxWidgets 3.0.2
libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.15.0-46-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.58.0
OpenCASCADE Community Edition: 6.8.0
Curl: 7.47.0
Compiler: GCC 5.4.0 with C++ ABI 1009
No. I told that the release announcement is a bit misleading here, but it wasn’t taken seriously.
KiCad 5.1 can be built with python3 support. Most platforms/packages don’t do it, I guess. Python 2 is the default. It’s possible to compile yourself if you want 3.
There are good heavy reasons to drop it for 6.0 but practical, technical, forcing reasons to keep it for 5.1. I believe everyone hopes the circumstances will be different when 6.0 is ready to come out and every package/platform can enable python 3 and that it will be the default configuration option. The situation where it can be either one is unbearable for plugin developers/users. I wouldn’t want to spend any time learning how to support both in a script. There are enough burdens already for plugin developers/users.
Yea but that should only effect microsoft builds. Why would it affect ubuntu (or any other of the sane platforms)?
Is this only a problem under the old 16.04 and we should point users to 18.04? (18.04 has python 3 as the official default and they seem to indicate that one needs special permission to get included if one uses python 2. Which is understandable as they might be worried about the security implications of including a package that will not be supported till the end of the lifetime of this release.)
I’m also waiting for the day Python 2 is finally obsoleted.
At the moment I’m still working with KiCad V5.0.2 on Debian Buster and do not have much in the area of scripting in KiCad. Only the Footprint Wizards work.
The Python website itself does not seem to be much concerned about motivating projects to (finally) switch to 3. At https://www.python.org/ I could not easily find any statement about obsolescence of Pyhon 2 and I’m afraid it will still be years before we finally get rid of it.
It will not be maintained past Jan 2020.
Which doesn’t mean it will immediately disappear in all distributions, of course. So yes, it will be here for years until we can get rid of it but nobody should be writing new software targeting python 2 if at all possible.
I agree that for KiCad 5.1 makes sense to stick to python2 because at the moment python3 dependencies are not available on all platforms. And plugin writers should update their scripts to be python3 compatible in preparation for v6 when it will be (hopefully) default. It’s not that hard.
I had no doubts that there would be an end of life statement on python.org somewhere, but the pointI was trying to make is that you have to go searching for it. It’s one of the disadvantages of open source software. The old stuff never goes away.
It seems that attempts to make people more aware of this deserves a more prominent place on the Python website.
When I now start python from the command line it still defaults to 2, and in the credits there is also no mention of it’s near end of life.
paul@dualcore:~$ python
Python 2.7.16rc1 (default, Feb 18 2019, 11:05:09)
[GCC 8.2.0] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
. >>>
co-existance of 2 incompatible python versions for 10 years is so mind boggling silly to me that I could not even take the whole language seriously and did not bother to learn it.
There is a long list of Python software on that site that is committed to stopping 2.7 support. This includes well known projects like NumPy, Matplotlib, Cython
Until/unless the list of projects committed to switching to 3.0 includes the projects that KiCad depends on, we are stuck with supporting 2.7. The alternative is removing scripting from Windows builds.
That said, individual packagers may choose to move to Python 3.0 for their supported systems. I think the Rawhide build and the Debian Sid build are there already.
According to Wayne issue is wxPhoenix not building under msys2. Is that the only thing stopping python3 on win? It may be possible to add a patch that can be incorporated in winbuilder.
That would be excellent. I think that is the only missing dependency. As we haven’t had a successful build yet, there may be lurking issues behind that as well.
I have not yet used Python scripts yet because of the wx and GTK problems with linux, but recently I switched to KiCad V5.1 and it claims to have scripting support according to the version info.
Scripting does not work (yet) however.
I think that with scripting you should have an extra icon on the left between “Hide board ratsnest” and “Show filled areas in zones”.
I do have a:
Pcbnew / Tools / Scripting console
(And an icon for it on the top of the screen), but when I try to start it, it barks at me with:
Debian Buster got frozen on KiCad V5.0.2. KiCad V5.1 was installed by temporarily setting the repositories to “unstable” and then installing KiCad, and after that setting the repositories back to buster.
Application: pcbnew
Version: 5.1.0+dfsg1-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.64.0 OpenSSL/1.1.1b zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Platform: Linux 4.19.0-4-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.67.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.64.0
Compiler: Clang 7.0.1 with C++ ABI 1002
