yield from statement is not python 2 compatible #295
Comments
|
Duplicate of #290. It installs OK, even though you see an error, and that module is only loaded if you're using the asyncio integration, so it's not a problem. Apparently if you upgrade pip, you'll no longer see the error. |
|
It does install OK in pip but only in pip and not in deb/rpm packages. python -m compileall $DESTDIR # destination dir in site-packagesFails it is compulsory for distribution packages to have |
|
Perhaps the distro packagers should remove that file for the Python 2 package? |
|
distro packages use the setup.py installer to build packages. Dsitribution packages do not have the capacity to inspect ALL python packages that exist to strip non compatible files. this should be handled in the setup.py |
|
For Python packaging it's fine to have a module which is only valid syntax on some versions of Python. If distros have additional requirements, I think its up to them to find ways to deal with that. |
|
pylint has the same "problem", recommend you investigate what your distribution does with pylint. |
|
I'm sorry, but mixing two types of code is wrong if distutils tools don't work. The following command should work: python setup.py bdist --format=rpmBut it fails with: please check: |
|
I am concerned that any accommodations made upstream to allow people to continue to build rpm's for python 2 distutils is not fruitful on this end. This is a battle you will continue with many projects going forward (what do you do about pylint, for example?), and you will have to find a general solution, just as pip has. Here's what I recommend, downstream, echo into MANIFEST.in during your build, Just please make sure to exclude such phrase when you finally switch to python3. Python 2to3 tool as suggested by your hyperlinks, and any of the other topics covered are for the reverse direction, how to switch to python3. They do not address the issue of using |
|
Thanks. Changing the MANIFEST.in may work but can not be automatized for every package in the wild. |
|
I know that setup.py file is capable. In technology, EVERY problem may be solved with code. I don't feel such code belongs in pexpect. pexpect is meant to solve a specific issue -- I don't feel it is right to join extra code with custom setup.py I suggest distutils bdist should ignore non-zero exit for compileall error for some files, in the same way pip does. Show me a distutils developer who says "I suggest pexpect project develop a custom find files function to workaround this issue" and I would accept a pull request to do the same. |
I intended to use tox to test packaging. Tox uses sdist and wheel last I checked. Pretty sure wheel is the future. Producing RPM's is only half the test -- does the rpm work? This raises volunteer costs significantly. |
|
You're also going to need to find another project and demonstrate how debian and rpm packages are made for such projects (I suggested you inspect the pylint package twice now). You might be suggesting a solution for something where precedent is already determined. |
|
To answer to your question about "does the rpm work", the answer is "No because it doesn't even build at all"... "python setup.py bdist --format=rpm" gives the traceback I pasted above, and doesn't even produce any rpm. So building an rpm is not possible automatically with distutils and has to be done by manual rpm packaging (meaning that non rpm packagers will not know at all how to do that). |
|
@ygbourhis I'm sorry I think my statement was unclear and misunderstood. I would really like you to understand why I take this stance: building an rpm successfully is outside the scope of pexpect The custom
To expand: It is my position that all new code is tested, and, the only way to test such code is by using "python setup.py rpmbuild" -- but this is only one half of the testing that would satisfy my standard. We must also ensure the rpm contents are correct! |
During a
pip installof the package, it fails with this error:This is because the
yield fromstatement is specific to python 3k.There are two solutions, either remove python 2 compatibility in setup.py, or not using this python 3 specific statement.
The text was updated successfully, but these errors were encountered: