No. We distribute Python and associated files as-is. But if you submit a PR to setuptools and it is merged, then we can pull that into KiCad for future use.
You must realize that this is impossible. KiCad is using an obsolete version of Python and hence uses an obsolete version of setuptools. The setuptools team could accept a patch, but wonât modify the obsolete version KiCad is using. We are talking about v44 when the last is v57.
BTW: I found a better patch, the root of the problem is that âsys.executableâ is asssigned a path using forward slashes and when the install_scripts.py script checks for the current executable detects a path with back slashes. Then the code tries to check if the script matches the value of sys.executable and it doesnât ⌠well just because of the slashes. Passing both sides of the comparisson by os.path.abspath solves the problem. Once the code realizes that the script will use Python executable you get the quotes.
From what I see sys.executable is some internal definition.
We are not releasing additional v5 KiCad packages. And v6 will use Python3 exclusively. So if this problem is only present in Python2, your best bet is to simply patch it locally.
I finally found a workaround: pip install wheel. With this installed pip installwill create a wheel package and in the process a different stub. The new stub contains the script to load the module and doesnât have any problem.
Conclusion: KiCad includes a broken setuptools. Things like python setup.py install will fail to create valid scripts for entry points.
Workarounds:
- Run the module explicitly, i.e.
python -m MODULE - Install wheel
pip install wheel
Note: always as administrator.
You are asking to any KiCost user to patch it locally.
But I know KiCad is handled this way, Iâll add instructions about how to workaround this problem installing wheel.
AFAIK this should be resolved in v6 as (I think) the build environment for v5.99 has transitioned to msvc. I have no idea what build environment v5.1.10 for Win was done in, but as an outsider to the dev circles my expectation is it was still on msys2 since the PYTHON3 build variable is still OFF.
Of course I know 
FYI, the kicad badge on our avatar means we are devs
5.1 will forever remain on msys2
Then where? In fact I use Debian GNU/Linux and always avoid using pip. I use it only to test if my Python scripts can be installed using pip, also to test a module before porting it to Debian. So I could say: pip was not really intended to work on Debian/Ubuntu/etc.
The idea of installing modules at user level and using virtualenv is just a hack, not a solution. On systems with a consistent package system pip is an ugly beast. Windows lacks a package system, so pip is more important there.
My bad. I had lost track of who was saying what.
@marekr Iâm just testing msys2 with the latest wxwidgets 3.1.5 and wxpython 4.11 which have been just released officially (thanks to Wayne @stambaughw that let me know this and helped on building)âŚ
https://packages.msys2.org/base/mingw-w64-wxPython (4.1.1-1)
https://packages.msys2.org/base/mingw-w64-wxWidgets3.1 (3.1.5)
Both kicad v5.1 and v5.99 build successfully
So it should be possible to have both v5 and v5.99 msys2 distro with py3.8 and wxpython4 enabled
Given the fact that Python 2.7 ended its life cycle more than one year ago it would be really nice to have a Windows/MacOSX v5.1 with a non-obsolete Python. Even if KiCad 6 is released soon. This will extend v5.1 life cycle. Not all people will be able to jump to v6 as soon this is released. In particular thinking about the multiple changes that v6 implements.
P.S. Sorry about suggesting more v5.1.x releases.
But why would we want to continue distributing msys2 builds with a fully functional msvc build that is also compatible with all native extensions on pypi? Itâs a maintenance burden on me and nick and we have plans to drop it.
The discussion is a bit confusing because there are many variables. The end users donât care about msys or msvc, they care about functionality. The question is if there could be an updated 5.1 with python3 and pip.
We donât have interest in opening more bug reports against 5.1 because the wxwidgets version changed.
Interesting ⌠wxWidgets 3.1.5 is more buggy than 3.0.2?
More buggy? No
Buggy in different ways? Sure, we have filed and fixed a few bugs in the 3.1 branch upstream as a result
But also there are some api changes that requires updates to the kicad code base. The kicad master contains these fixes, nobody is interested in backporting to 5.1. We have no desire to maintain 5.1 beyond notable bug fixes.
A pitty that these things werenât backported to the stable release.
Yes, and pitty that there wonât be even bugfixes. There are still two possibilities: 1. Pay for someone (KiPro) to do the work. 2. Find a new team willing to take the responsibility for the 5.1 branch to fix bugs and backport the python features.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.