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!
It’s not missing. It’s in /lib/python3 instead
We aren’t dropping MSYS2 support, you will be able to build it yourself using it.
However MSYS2 is a complex beast that’s not usable with any IDE. I and others do not have the free time to fight the beast. MSVC has Visual Studio as its main IDE, and even alternate IDEs (CLion, Eclipse) support its toolchain. Microsoft is also very supportive of building all our dependencies via vcpkg with no effort needed by us mostly.
On the other hand, I can’t even file an issue with MSYS2 without the maintainers attacking me for not submitting a merge request. Because they are quite overloaded, but so are we.
1 Like
@nickoe grrrr nick, why did you include them! (in the lite packages only oddly)
They are useless to 99% of users who will need to waste bandwidth on them
great info! 
thx a lot! 
