Seems like we should deal with this better.
I got this on:
Step 17 : RUN cookiecutter https://github.com/pydanny/cookiecutter-django --no-input
[91mTraceback (most recent call last):
File "/usr/local/bin/cookiecutter", line 11, in <module>
sys.exit(main())
File "/usr/local/lib/python3.5/site-packages/click/core.py", line 700, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.5/site-packages/click/core.py", line 655, in main
raise RuntimeError('Click will abort further execution '
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Either switch to Python 2 or consult http://click.pocoo.org/python3/ for mitigation steps.
[0m
For more details, see:
The error prompts you to g to http://click.pocoo.org/5/python3/, where the problem we're having is specifically mentioned in http://click.pocoo.org/5/python3/#python-3-surrogate-handling. The solution provided there is to change the LC_ALL and LANG values to match your regions locale. Example, if I'm in US I would set:
export LC_ALL=C.UTF-8
export LANG=C.UTF-8
@hackebrot, on the other hand would do the following:
export LC_ALL=de_DE.utf-8
export LANG=de_DE.utf-8
While this is easy enough to do on an individual basis, it's arguably an impossible solution for Cookiecutter. Especially when it comes to newcomers. Of course, Cookiecutter itself could change those environment variables when needed, but that's an ugly and potentially damaging 'solution'.
While this is easy enough to do on an individual basis, it's arguably an impossible solution for Cookiecutter. Especially when it comes to newcomers. Of course, Cookiecutter itself could change those environment variables when needed, but that's an ugly and potentially damaging 'solution'.
@pydanny I would argue that not setting LC_ALL and LANG is a wrong set-up environment. And in such a matter, that this needs to be individually customized per region it is impossible for any automated solution to be agnostic and do the right thing.
On the other hand, the only thing I dont like about the shown error message, is that it is (at least not straight forward) not clear enough for a newcomer.
I guess, that cookiecutter could check against set LC_ALL and LANG and in case one of them is not set, raises an error (with clicks informations and additional informations that points one straight to setting the two variables)?
Also documentation that discusses this error could be helpful, I guess (FAQ Section?).
I think forcing people to figure out how to set their local language type is a bad idea. As much as I like Click, this is a pretty big hurdle for the "instant compatibility" we like to have on this project.
Here's a cumbersome fix we could try: http://stackoverflow.com/questions/32234393/encoding-issue-with-python3-and-click-package
I'd prefer to have a user-friendly error message that tells to set up LC_ALL and LANG but also points to our rtfd. :smirk_cat:
I think forcing people to figure out how to set their local language type is a bad idea.
I completely agree.
I dont know click good enough, but whenever you need to guess (force) a certain behavior related to these settings (better, if you need to force something related to these settings), your best bet is to check against LC_ALL, which overrides ALL custom LC_* variables.
What I don't get (and did not test yet) is whether it is needed to set both variables (which makes no sense to me). In my opinion it should be enough to set LANG. Did anyone test that yet?
LANG should really be set on any Linux. For desktop installation this is the case anyways as soon as you choose a language (which sets the LANG normally) using one of these modern WYSIWUG install wizards.
A good explanations about these variables can be found at https://unix.stackexchange.com/questions/87745/what-does-lc-all-c-do (choose the answer with ~100 upvotes).
https://twitter.com/mitsuhiko/status/662383781907709953 :heart_eyes_cat:
Most helpful comment
I think forcing people to figure out how to set their local language type is a bad idea. As much as I like Click, this is a pretty big hurdle for the "instant compatibility" we like to have on this project.