pipmain ([‘install’, ‘–user’, ‘\pip\numpy-1.16.4+vanilla-cp27-cp27m-win_amd64.whl’])
[33mRequirement ‘\pip\numpy-1.16.4+vanilla-cp27-cp27m-win_amd64.whl’ looks like a filename, but the file does not exist [0m
[31mpip
umpy-1.16.4+vanilla-cp27-cp27m-win_amd64.whl is not a valid wheel filename. [0m
1
or:
pipmain ([‘install’, ‘–user’, ‘numpy-1.16.4+mkl-cp27-cp27m-win_amd64.whl’])
[33mRequirement ‘numpy-1.16.4+mkl-cp27-cp27m-win_amd64.whl’ looks like a filename, but the file does not exist [0m
[31mnumpy-1.16.4+mkl-cp27-cp27m-win_amd64.whl is not a supported wheel on this platform. [0m
1
Numpy file is in \pip folder. It should find it there. However, pip reports it creates files but the location shows no such file was made. In the instance with dxfgrabber I created the missing file and pip installed dxfgrabber on the 2nd try. With wheels my experience is the opposite I create the file and pip will create another phantom with a different random suffix and again put nothing in it.
Worked on this for 3 days now to get this far. Any suggestions ?
Thanks in advance !
Numpy is troublesome because it’s “installation” script requires some compilation. Precompiled whl files that can be found on https://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy don’t work because the file name structure is not correct (whoever came up with that brilliant idea should never be allowed near any software distribution system).
If you download numpy‑1.16.4+mkl‑cp27‑cp27m‑win_amd64.whl
and rename it to numpy-1.16.4-cp27-cp27m-mingw.whl
installation will succeed but I can not guarantee numpy will work.
I would suggest reconsidering using numpy in the first place.
Also if you want your work to be usable by others and plan to publish it some day, the less non-packaged dependencies your code requires the better.
@qu1ck
Thank you. I understand all of the complications with Numpy it was one of the packages required in the scripts offered from https://kicad.mmccoo.com/.
Yes, I agree. Avoiding scripts that rely on complex packages such as Scipy and Numpy would make things more understandable.
It was a challenge so I spent some time trying to get Numpy installed with very scant details otherwise. If those scripts were developed instead of using Fusion 360, used in process programming with a version of AutoCAD with aLISP scripts it would be more clear and straightforward. KiCAD users could then experiment with a CAD having aLISP capabilities like IntelliCAD.
I have generated blocks of PCBnew copper layer code from within a version of IntelliCAD then submitted the results to OSHpark with outstanding in hand results but I need to do more work to make the methods more linear. Graphics and cut lines are a piece of cake.
Numpy could be easily included on win packaging.
I remember that I used to install numpy on my kicad winbuilder chain, and then adding it to my kicad bin folder.
I understand that. Python and aLISP make it easier to use both KiCAD and CAD for its geometry engine side by side on same machine for custom trace layouts, etc.
Awhile back just ran across McCoo’s work and wanted to check it myself to compare it to my work but info on how he implements his KiCAD PCBnew plugins or scripts for passing the KiCAD or Fusion data back and forth between KiCAD and 360 is scant. I only know for sure he has a Linux set up, I do not, but I try to keep focus on both Linux and Windoz platforms as I go along.