Be sure to check the existing issues, both open and closed.
Describe the issue briefly here.
I use gobal pipenv, which located in python27 folder, install python3 project, using python3 interpreter.
python3 project locate: https://github.com/hugsy/cemu
Installing -e .…
Traceback (most recent call last):
File "C:Python27Scriptspipenv-script.py", line 11, in
load_entry_point('pipenv==9.1.0', 'console_scripts', 'pipenv')()
File "c:python27libsite-packagespipenvvendorclickcore.py", line 722, in __call__
return self.main(args, *kwargs)
File "c:python27libsite-packagespipenvvendorclickcore.py", line 697, in main
rv = self.invoke(ctx)
File "c:python27libsite-packagespipenvvendorclickcore.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "c:python27libsite-packagespipenvvendorclickcore.py", line 895, in invoke
return ctx.invoke(self.callback, *ctx.params)
File "c:python27libsite-packagespipenvvendorclickcore.py", line 535, in invoke
return callback(args, **kwargs)
File "c:python27libsite-packagespipenvcli.py", line 213, in install
deploy=deploy
File "c:python27libsite-packagespipenvcore.py", line 1757, in do_install
click.echo(crayons.blue(format_pip_output(c.out)))
File "c:python27libsite-packagespipenvvendorclickutils.py", line 221, in echo
message = text_type(message)
File "c:python27libsite-packagespipenvpatchedcrayons.py", line 88, in __unicode__
return value.decode('utf8')
File "c:python27libencodingsutf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xb2 in position 4264: invalid start byte
This looks to me like we might be attempting to decode mbcs
from the Windows console as UTF-8.
@mmyydd Does the install behave itself if you use Python 3.6 to run pipenv
and pip
as well? (3.6 changed how the console gets handled on Windows, such that decoding with utf-8
should more reliably do the right thing).
From experience, this error message usually suggests there is an underlying issue happening, usually in a subprocess. I would even venture to guess the issue is OSError-derived, most of those contain localised messages on Windows.
@uranusjr Getting Python 2 to play nice with the standard Windows console can be a little interesting: https://pypi.python.org/pypi/win_unicode_console goes over some of the problems with it.
Python 3.6+ is a fair bit easier to use though, since Steve Dower moved a lot of the console encoding handling over into the Python runtime, which is what makes it possible to mostly avoid encountering mbcs
.
@mmyydd it is highly recommended to install pipenv with python 3 if at all possible, especially on windows.
Crossing python version boundaries from python 2 to 3 poses plenty of problems on its own, but if you haven't made the necessary console adjustments you're going to have a hard time (and you still might)
Resolution: use Python 3. I'm considering dropping support for 2.
Yeah +1 to Python 3-only, especially because sounds like python 3 pipenv
can manage python 2 projects just fine.
On Fri, Feb 23, 2018 at 10:11 AM Kenneth Reitz notifications@github.com
wrote:
Resolution: use Python 3. I'm considering dropping support for 2.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/1457#issuecomment-368092214, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjq1fWShnaUK0Chc7LwF16aBBDVNC3ks5tXv9VgaJpZM4SNk0n
.
@kennethreitz I think the main problem with dropping Py2 support completely right now is that #857 means that a Py3 pipenv may not generate a correct lockfile for Python 2.7 virtual environments.
So if we did drop support for running pipenv under Py 2.7, we'd likely have to drop official support for directly managing 2.7 environments as well (or at least emit a warning that some dependencies might be missing).
However, if we're able to figure out a way to fix #857, then I'd definitely be +1 on requiring that pipenv
itself run under Python 3.x (perhaps even going so far as to require 3.6+, because f-strings are really nice).
We can't drop 2 support, just discourage it.
Use case: Heroku.
Sent from my iPhone
On Feb 23, 2018, at 10:53 PM, Nick Coghlan notifications@github.com wrote:
@kennethreitz I think the main problem with dropping Py2 support completely right now is that #857 means that a Py3 pipenv may not generate a correct lockfile for Python 2.7 virtual environments.
So if we did drop support for running pipenv under Py 2.7, we'd likely have to drop official support for directly managing 2.7 environments as well (or at least emit a warning that some dependencies might be missing).
However, if we're able to figure out a way to fix #857, then I'd definitely be +1 on requiring that pipenv itself run under Python 3.x (perhaps even going so far as to require 3.6+, because f-strings are really nice).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Most helpful comment
Resolution: use Python 3. I'm considering dropping support for 2.