-
Notifications
You must be signed in to change notification settings - Fork 476
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot install pexpect 4.0 with python 2.7 #290
Comments
It shows the error, but the install should have actually completed (at least, this is what I've found before). The asyncio integration is only usable on Python 3.3 and above, but it shouldn't try to load that module unless you're using it, so it shouldn't be a problem. I don't know of any way to prevent Python 2 from complaining on installation, but as far as I know it doesn't have any actual effect. |
@martinsmid upgrade pip and the error goes away. pypa/pip#1984 |
(also -- not an error! your installation is fine, enjoy !) |
It does install OK in pip but only in pip and not in deb/rpm packages. python -m compileall $DESTDIR # destination dir in site-packages Fails it is compulsory for distribution packages to have |
For packagers of pexpect, this is a real bug, so please reopen it until it is properly fixed. |
I'm sorry, but we don't consider this a bug. There is a module that can, by design, only be loaded in Python 3. This is not a problem for the primary mechanisms used to distribute and install Python modules. Where other packaging systems have a problem with this, packagers will need to work around it - for instance, by removing We distribute a single package for Python 2 and 3 (and we don't want to change that), so we can't remove the file from our packages. |
@ignatenkobrain did exactly that in Fedora: |
Ok, I've done the same for Debian. What I don't like is that if somebody passes |
Yeah, making that something like a not implemented error makes sense.
|
takiuyver, FWIW, "pip install" is NOT the "primary mechanism used to distribute and install Python modules" on any system with a system package manager (and perhaps even other systems too). Being hostile to the requirements of package managers is not a useful attitude. |
Actually, on my Linux machines, pip is the primary way that I install Python packages ;-). I'm not hostile to other packaging systems, but there's nothing we can easily do to solve this on our end, whereas it should be easy to for packagers to workaround - by excluding that file from the Python 2 package, or ignoring failures in byte compilation like pip does (since there's no guarantee that every file with a .py extension is valid Python syntax on a particular version of Python). I'm happy to work with packagers to find constructive solutions, but I've got a bit irate with this particular issue because we've had several duplicate reports of it, and I somewhat resent the suggestion that we should change how we code to accommodate packaging mechanisms that can't cope with one module in a package being Python 3 only. |
Sure, but it's not the primary way of the OS; your choice to use pip is non-standard (at least for system-level installations; mixing distro packages and pip doesn't seem like a good idea to me. Perhaps you use virtualenv for everything though, so that objection isn't relevant). Besides (and this is the reason I came here) pexpect doesn't (at least appear to) install correctly even using pip. There's a big failure message printed during installation. Sure as per the comments above it turns out you can just ignore that, but I'd hardly call that a good user experience. (BTW "ignoring failures in byte compilation like pip does" is a bit economical with the truth; ignoring the issue would imply that it doesn't spit out error messages that users can see.) Surely the fact that there are duplicated reports of this issue shows that multiple users are affected by this problem Surely it would be better to solve it than getting irate about people (rightfully) reporting issues they experience? Finally, if I were a distro packager, after having reported the issue, I would find "I'm sorry, but we don't consider this a bug." to be quite hostile. Two simple things you could do to avoid users seeing this problem: a) Mark the latest pexpect as being compatible with Python3 only. b) Producing two separate packages for Python2 and Python3 installations. I believe I've seen other Python-based projects do this. Assuming you have a script to generate release packages, this should be as simple as doing the same thing for both packages, and then deleting a single file in one case. If you do this, you save every distro maintainer (and person installing using pip on Python2) from having to duplicate that same work. |
Recent versions of pip do not show the error message.
That would be inaccurate. We write and test it to work on Python 2.7, so we're certainly not going to claim that it doesn't. Only the asyncio integration requires Python 3.
If anyone has constructive thoughts to add to this, please do so. But I am not interested in repeatedly justifying the decision we've made against the same complaints, and if this thread goes on like this, I intend to lock it. |
Please do not that it's not only distro packagers that have to deal with this issue, but every single user who installs the package via pip (apparently only if they're not using the latest version of pip). On Ubuntu 14.04 for example, people will see this issue. Other than that, OK sure, I'll stop attempting to get this legitimate issue fixed so that users aren't affected by it. |
They have to deal with it by ignoring an error message on installation, yes. There is nothing extra for them to do, and they can use Pexpect as normal. The pip developers seemingly considered it a bug that the error was shown when install succeeded, which is why the latest version of pip does not show it. |
Just to mention that this issue is also annoying for the Buildroot project, where we have to remove async.py manually to make the byte-compilation process work with error with Python 2.x. |
pexpect contains one file, async.py, that is only meant to be used with Python 3. Due to this, it fails to byte-compile with Python 2, which will become a problem once we make byte-compilation failures fatal failures that abort the build. As suggested by upstream at pexpect/pexpect#290, we simply remove the problematic file when building with Python 2. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It would be nice to get an |
Maybe this is just an docs issue (http://pexpect.readthedocs.org/en/stable/install.html#requirements), however pexpect >=4.0 does not work with python 2.7, because it uses a python 3.3 syntax (yield from).
It is not clearly stated in docs and the install fails with a syntax error.
https://github.com/pexpect/pexpect/blob/master/pexpect/async.py#L16
The text was updated successfully, but these errors were encountered: