-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Non-ascii error with pip install #2501
Comments
Is there any way I can fix this just for myself? If not when should I expect this to be fixed? |
I think that the correct fix is to not use such paths. Although unicode filenames are a reality of modern systems, pip (and Python) are known for their terrible support of it. There are probably a lot of such places throughout the code (see #2521), and unless the pip team comes to care and test for it, it will never be reliable. |
Looking at the trace, it appears the issue is in the vendored lockfile module. If you could reproduce the issue just using lockfile and report it to that project, that would be a huge help, as we could then upgrade to the fixed version once it gets released. That's all the pip developers would do anyway, as we don't, as policy, modify code that we vendor. |
For anyone else who may get this problem this is how I fixed it for myself:
Pro-tip: Avoid giving your children names with non-ascii characters |
Please someone reopen this. This is definitely a bug with pip, it is supposed to be unicode safe. The fact that there is a workaround doesn't erase the fault. |
Agreed this is a bug. It's possibly only in 2.x (the OP hit the bug in 2.x, but his "fix" uses no non-ASCII username and uses 3.4, so it's not possible to tell) because it seems to be a result of string/unicode confusion. I believe that it's the sort of problem that "just works" in 3.x, because it's a consequence of the broken "mixed bytes/string model" in Python 2.x. Also, it's probably a bug with one of the vendored packages (CacheControl or lockfile) being unable to cope with being given a Unicode path for the cache/lockfile directory. From the traceback, I'm not sure which of the two would accept responsibility for the bug. Pip uses a directory under the user's home directory for the cache - cachecontrol puts the cache there and appears to ask lockfile to create its lock file in that directory, so either or both needs to be prepared to be passed a non-ASCII directory name. My bet's on the bug being with lockfile. I have reopened the issue, but it needs someone to reproduce the bug and open an issue against the lockfile project. Ideally such a bug report should include a test case that is independent of pip. This issue can then be closed when that reported bug is fixed and a new release of the relevant library is vendored into pip. @remram44 would you be able to reproduce and raise such a report? I'm assuming the OP isn't interested in doing so, as he's now worked around the issue... |
I can't reproduce this on pip 7.0.3 in a win7 VM with a non-ascii username and homepath (but I'm probably not running into the right condition?) When is the lockfile used? |
Can it be reproduced with pip 6.0.8? Maybe it's fixed at the pip end since then? Were you not encountering this issue yourself? |
Not with 6.0.8 either. I don't have a Windows machine anymore, I'm running this in a clean VM. |
OK. @OisinMoran do you have the means to reproduce this any more? If we can't reproduce it, I'm inclined to re-close the issue as cannot reproduce. When it comes up again, we'll get a new issue with a test case and we can report it to the lockfile project |
Fortunately/unfortunately it works fine for me now so cannot reproduce the error sorry! |
OK, I'm going to (re-) close the issue as not reproducible. Should it occur again, hopefully we can get a test case across to the lockfile project. Or if someone wants to raise an issue now against lockfile, noting that when asked to create a lockfile in a directory with a non-ASCII name, it fails, pointing at this issue as an example, then that would be fine too :-) |
I figure out what was wrong in my case - my full computer name was "ПК" which is "PC" in russian and whenever join function trying to
to this
|
This was just reported by a user of lektor as something that is still happening on Russian windows PCs:
|
Just had this issue myself. Installing latest Python 2.7.12 didn't help, but @Andrej730 workaround worked! Tried to update the pip and it immedeatly reverted to the old buggy code, so the issue is definitely not fixed! |
I can confirm this bug still exists in pip 8.1.1 . I'm using a russian Windows 7 Version 6.1 (Build 7601: Service Pack 1) with a user name and a computer name that uses cyrillic letters.
I can also confirm that the workaround from @Andrej730 solves the issue. |
Another report with pip 9.0.1: Error:
Pip version: |
@pfmoore maybe reopen this issue? Hard to tell if our feedbacks are getting ignored because they are considered to be fixed. |
@danilaml To reopen, we'd need a reproducible test case. Specifically, that means a script or set of instructions that reproduces the issue, without relying on the setup of the user's PC. Specifically, if it only happens when the user's name contains non-ASCII characters, then the reproduction script would need to mock out the relevant stdlib calls, as you can't guarantee that the user trying to fix the issue has a non-ASCII username. As this is clearly an issue that keeps cropping up, we'd really want to add a test to pip's test suite to demonstrate it - so a report that included precisely such a test would be ideal. But with sufficiently clear instructions, we could write such a test (but again, note that our Windows CI server, Appveyor, doesn't run the tests with a non-ASCII user account, so we're back to the point about needing to give us a test that an ASCII-only user can run). I appreciate this is a lot to ask. But as a volunteer group, with no-one paid to work on pip, the pip developers simply don't have the resources to spend trying to track down this issue. We have tried, by simple code inspection, and you're telling me that we haven't managed yet, so we need to look at other options. An alternative would be for someone to submit a PR containing a fix. But ideally I'd still want such a fix to include a test, so that we don't risk regressions. So, I still think this issue should not be reopened. If someone has a full set of reproduction steps, feel free to open a new issue describing those steps. If I can run them, and demonstrate the issue, on my PC, then we'll be making progress. I can at least mark the issue as verified in that case (I won't promise to be able to fix it for you - volunteer organisation, remember :-) - but at least we'll have something someone can then work on productively). Or if someone wants to provide a fix, then they can create a PR, and reference this issue. The people who've reported still having the problem here can then test with the fix, and feed back on the PR as to whether it resolves the problem. Note The other point is that the reports all still seem to have been showing that the vendored |
@pfmoore sorry for the late reply, but I've investigated the issue and it seems there is a way to run tests under user with non-ascii characters in user name on appveyor (thanks to their awesome support). Here is my proof of concept branch: https://github.com/danilaml/pip/blob/test-non-ascii-user/appveyor.yml |
@danilaml Thanks very much for doing that - apart from the specific case here, it's nice to have an example of how to write tests like this on Appveyor. Having said that, the failures here are in tox, before we even start running the pip tests. So it's not showing an issue with pip. It might be worth raising the problem you've demonstrated with the tox project, but it doesn't help with confirming the situation on this issue, sadly. |
Sam as @rvilla87. Any update on this? |
@B3zo0 This is a different issue. Please open a new issue with a full description of how to reproduce including the full traceback you get. The report by @rvilla87 is confusing, as it shows a decode error from an encode operation. My suspicion is that this may be somehow related to Python 2's limited Unicode model, but we'd need more testing to confirm that. |
Hi During handling of the above exception, another exception occurred: Traceback (most recent call last): |
Trying to use pip install but keep getting this message. Think it may have to do with the 'í' in my name (Oisín) as that is in my path name.
Using pip 6.0.8 on Windows with Python 2.7
The text was updated successfully, but these errors were encountered: