I use SolydK 10 64-bit Debian linux. APT shows no numpy package.
Kicad windows nightlies will soon have python3.9 support
3 Likes
Centos (streams) is great if you want long term stability but not great if you want newer (ie in the last 5-10years) of libraries. Its more geared towards servers and professional workstations rather than desktops
Fedora is a good option if you want to stay with the redhat brand
I also tried a nightly build following: KiCad 5 and nightly builds for Fedora Linux – maybe fedora is different enough from centos that this won’t work…I don’t really know what I’m doing.
Thanks for trying to use my Fedora nightly builds! Unfortunately, they are currently not up to date. I’m working on some changes to the packaging scheme, and it will take another week or two until they receive the next update.
If you want to use nightly builds of KiCad on Fedora, please use the official Copr repository @kicad/kicad instead.
Independent of that: You can not use the Fedora nightly builds on CentOS (neither the old version 7 nor the current version 8). Some of KiCad’s dependencies are either outdated or not available at all on RHEL/CentOS.
If you want to play with the KiCad Python scripting interface and don’t mind to set up a dedicated (virtual) machine for that, I would recommend to use Fedora 33 and the stable release 5.1.9 (plus numpy, scipy, or whatever else you might need) from the Fedora repositories.
there is a numpy release even under MSYS2 mingw-w64-x86_64-python-numpy that can be used/distributed even under python2.7 win
https://packages.msys2.org/base/mingw-w64-python-numpy
1 Like
Kicad windows nightlies will soon have python3.9 support
@marekr How can I track the status of this? And / or try it out?
Is WSL2 on windows with python 3 an option for me? KICAD_SCRIPTING_PYTHON3=OFF on Windows for 5.1.9-1.9
It’ll be announced, it’s part of our migration to MSVC based builds. Soon…hopefully…the holdup is out of my control 
Is WSL2 on windows with python 3 an option for me?
Maybe? I am not a particular fan of using WSL2 for GUI related items and it can introduce bad behavior that we may not get around to fixing
so kicad is leaving open source build MSYS2 platform switching to closed source compiler/environment?
Does it matter when the platform itself, Windows, is closed source? It’s a practical decision, not ideological. Apparently Open Source would have been preferred if it had worked.
1 Like
it does matter for me (and I think I’m not alone)… to get the building chain you need to use a proprietary compiler within all the issue related.
??? the ‘only’ stopper afaik is wxpython 4 (with py3 support) built for windows msys2
there were some wip
is that been abandoned?
[EDIT] it seems it has been solved here:
The snapshot wxPython-4.1.2a1.dev5156+3500ac7a.tar.gz wxPython now compiles on MSYS2 and can be imported in python.
1 Like
There are now some msvc based builds available for testing at https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/testing/
While I do agree with you on this, there is a benefit in using a totally different toolchain… bugfinding since a different toolchain will interpret the src differently. Blizzard built WoW with a native linux version purely for this reason (never released as its one thing to find bugs, its another to release and support a client).
The flipside is if/when compiler specific bugs result in boilerplate code to make it work … think websites and all the IE hacks that had to be added.
How do you know for how long a ‘free’ version of a commercial compiler would be keept ‘free’… then all your effort in changing the code to adapt to the ‘commercial’ compiler would be thrown out and you would be back again in searching a new solution for what you have already discharged.
This happened so often in the past that I cannot understand why it still on the way to move…
1 Like
AFAIK the original work and decision towards MS tools for KiCad was driven essentially by the python/wx problem. If it happens that MS stops supporting their free compiler tools, I’m pretty sure that it affects a huge amount of Open Source projects which then must move to mingw, including wx. In that case all needed libraries etc. would be supported for mingw again so that KiCad can move back. KiCad wouldn’t be in any worse position than maybe thousands of other projects, and there would be enough pressure so that KiCad project doesn’t need to worry about that.
This is just my personal opinion, anyone can disagree freely and give counterarguments, I may change my mind on this.
‘if’ or ‘when’? 
it seems to me you don’t know ms enough.
1 Like
It’s in MS’s best interests to support free compiler tools. Even more, it’s in their interest to support free edition of their best product ever made, Visual Studio. It was their mistake to not make it free from the start but for the longest time they had a crazy bald guy jumping on stage in a drug fueled frenzy for a CEO so whatcanyado… They are moving in the right direction now.
I may disagree
1 Like
@nickoe I just installed latest msvc build and scripting doesn’t work in it (unable to create Python Console), and running import pcbnew in python if launched separately fails with unable to load _pcbnew library.
Is it expected that python.exe is now moved to ./lib/python3 instead of ./bin ? Also there is no pip.exe.
Is it expected that installer copies debug symbols for every library? I downloaded non dbg build but maybe they are all dbg now?
@qu1ck I don’t really remember what we decided to do there. Having the python.exe being missing is also unexpected for me, but we should track this discussion in an issue on https://gitlab.com/kicad/packaging/kicad-win-builder instead.
I just wanted to highlight that progress is being made, not that is is completely done yet 
Thank for testing anyways!