Pip installation fails #305
Comments
|
Installing from master works with Python 3.7rc1 and NumPy 1.14.5 (passes all tests too). |
|
FWIW pip of 2.6.5 also fails for me at the same place. |
|
For some reason the files have two LFs so that lines have an extra vertical between them. This might be a Python 3.7 bug -- the source file is fine when installed |
|
Hmmm.. maybe this is an artifact of the |
|
I can't compile NumPy with 3.7rc1 on Windows without unresolved references to BLAS, so unless there's documentation somewhere (Tried: https://docs.scipy.org/doc/numpy/user/building.html setting environment variables to None) that's as far as I'm willing to go on my own. |
|
You don't need BLAS or LAPACK to install NumPy on Windows (of course, one would want these in production). You can just build from master or a source tarball, and then numexpr can be built and tested. |
|
I think this has to be a Python 3.7/Windows bug. I can't imagine how the source file on PyPi, which does not have extra FWIW it is fine to pip install from a git repo, but a pip install from PyPi always inserts the extra |
|
Interesting... Especially since everything else I install/compile works fine using pip. Another weird issue is that previous versions of numexpr didn't have this issue or it is local to certain set-ups. A colleague of mine installed it without issues just a few days before me. I'll try the git install next as suggested. Thanks for your time trying to fix it.
You could try installing with pip from this site: https://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy |
|
Updating this; I found out the issue is due to the infamous notepad bug as hinted at by bashtage. I don't know where it was introduced, but it's definitely visible in my source file in "C:\program files\python37\Lib\site-packages\numexpr\necompiler.py". The line-breaks show 0D0D0A on every line-break in a hex editor instead of the correct 0D0A on Windows. I'd assume the issue doesn't appear in Linux. It does not appear in the binary install. Direct source download from github is also unaffected, so as said, that's a good workaround as well. Reportedly it's an issue with the revision control system used, whether that's on PyPi's side or yours I wouldn't know. |
|
So how are they getting there? They aren't present when I clone the repository on Windows. yields: |
|
Since this only happens with a source tarball from PyPi on Python 3.7 (but not with source on Python 3.6), I assume they are getting there through a bug in Python 3.7. |
|
The underling issue with the The broken line endings seem to be a separate issue. |
|
@bashtage, can you try running the `2to3` script from 3.7 on the source
tarball and see if the line endings change?
On Fri, Jun 29, 2018 at 3:13 PM, Kevin Sheppard <notifications@github.com>
wrote:
… Have you looked at the tar.gz? It is normal and there are no strangle line
endings in the file that fails, only an unfortunate line continuation that
won't parse with and extra break.
On Fri, Jun 29, 2018, 22:59 Unprocessable ***@***.***>
wrote:
> Yeah, right, well, if you've found the Python bug, feel free to report it
> then. Otherwise I'll just assume Numexpr is to blame. Could you re-upload
> it maybe to the repository that's used by pip?
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#305 (comment)>,
or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/
AFU5Re3JGbuwEL2kYabpkW1VWm4SUNt3ks5uBqNWgaJpZM4UsBti>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#305 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFuMmXl3gOol7HKWiztKlKqwDNI1lLPGks5uBqaWgaJpZM4UsBti>
.
--
Robert McLeod, Ph.D.
robbmcleod@gmail.com
robbmcleod@protonmail.com
robert.mcleod@hitachi-hhtc.ca
www.entropyreduction.al
|
|
@robbmcleod That is precisely where the problem is occurring. The file is fine before 2to3 (Python 3.7) and munged after. Running 2to3 from Python 3.6 works as expected. |
|
I would guess the changes made here are the source of the problem: |
|
Actually, that would mean the line endings were wrong in the source files, if they are preserved when using the fixed 2to3 script, which only comes to light now. Unless the fix causes extra line-breaks, which seems counter-productive. So are all the files uploaded to pip saved with Unix style line-breaks? |
|
The line endings are CRLF. If the source file is CRLF and the tar if built on Windows, then it will be CRLF on PyPi. Every installed file is munged and has CRLF->CRCRLF. necompiler fails since it has a split line , context['truediv'] = \
caller_globals.get('division', None) == __future__.divisionFor example, becomes Pretty clearly a bug in 2to3, and some bad luck. Tests probably didn't have split lines. |
|
Paging @aaronang, as you seem to be the last person who did a PR on the CPython 2to3 library. Would you please have a look at this issue for |
|
See python/cpython#6483. Currently, I can't reproduce the problem with a test. I am waiting for someone to run it on Windows to see if that test fails. |
|
Are you testing on Windows? It doesn't occur on Linux.
|
|
@bashtage I am not. Unfortunately, I don't have a Windows machine available 😞 |
|
Can you us Windows CI and a test file that looks like which 2 to 3 translates to and is invalid. |
|
It should be fixed: python/cpython#8271. |
|
Ok thank you for the assistance, closing. |
Uh oh!
There was an error while loading. Please reload this page.
I have no idea how long I've been working on this issue and I don't really care. The installation of version 2.6.5 of numexpr using pip 3.7 fails on Windows 10, 64 bit with equivalent Python version 3.7. The error I got was:
Could not install packages due to an EnvironmentError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '"c:'
My PATH variable was set correctly and numpy + mkl 1.14.5 was installed correctly too. In pandas I used the HDF5 storage to save data to disk. This requires tables, which requires numexpr. I'm using the newest version of Visual Studio (2017), I don't know if that's a requirement, but it's there. You'd understand my frustration seeing as I had numexpr installed (and everything seemed to run fine), yet the issue only showed up once I imported and used tables in my script (on ne_compiler.py). I removed and reinstalled every other library thinking the issue was there.
I ran pip with the --log option, the data is below. The binary pre-compiled version of numexpr runs fine.
The text was updated successfully, but these errors were encountered: