open readme.md with codecs.open

[yassersouri]

We were installing the package on a machine when this happened:

    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "/tmp/pip-build-6jkee90k/riak/setup.py", line 25, in <module>
        import pypandoc
    ImportError: No module named 'pypandoc'

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-6jkee90k/riak/setup.py", line 31, in <module>
        long_description = f.read()
      File "/venv/bme/lib/python3.5/encodings/ascii.py", line 26, in decode
        return codecs.ascii_decode(input, self.errors)[0]
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 5207: ordinal not in range(128)

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-6jkee90k/riak

I think this might fix the error.

[lukebakken]

Thank you, this has already been fixed in 4325130

[yassersouri]

It has been fixed for README.rst while writing it. I think it needs to be added for README.md when reading it.

[lukebakken]

I missed that this is in the exception handler. Thanks for the fix.

[lukebakken]

@yassersouri - can I ask how you found this issue? Did you clone this repository or was it via pip install?

[yassersouri]

It was though pip install.

[lukebakken]

@yassersouri - that's interesting, I can't reproduce this error in my environment. Could you please provide the output of the following commands in your environment? What operating system are you using, and are you using the system Python or a local account one?

• python --version
• pip list
• pip show riak

Here is the output of pip install riak in a clean virtualenv using Python 2.7.11:

$ pip install riak
Collecting riak
  Downloading riak-2.5.2.tar.gz (193kB)
    100% |████████████████████████████████| 194kB 748kB/s
Collecting six>=1.8.0 (from riak)
  Downloading six-1.10.0-py2.py3-none-any.whl
Collecting basho_erlastic>=2.1.1 (from riak)
  Downloading basho-erlastic-2.1.1.tar.gz
Collecting protobuf<2.7.0,>=2.4.1 (from riak)
  Downloading protobuf-2.6.1.tar.gz (188kB)
    100% |████████████████████████████████| 194kB 1.1MB/s
Requirement already satisfied (use --upgrade to upgrade): setuptools in ./.pyenv/versions/2.7.11/envs/lrb-test/lib/python2.7/site-packages (from protobuf<2.7.0,>=2.4.1->riak)
Building wheels for collected packages: riak, basho-erlastic, protobuf
  Running setup.py bdist_wheel for riak ... done
  Stored in directory: /home/lbakken/.cache/pip/wheels/33/49/f9/d728fe24f94cd2a1460c6aa4d2b39b31ad2c3d7b4b800a7903
  Running setup.py bdist_wheel for basho-erlastic ... done
  Stored in directory: /home/lbakken/.cache/pip/wheels/30/58/2a/b7e474faf51bdd14ef0fea64777011a3811fa4c884733c9d69
  Running setup.py bdist_wheel for protobuf ... done
  Stored in directory: /home/lbakken/.cache/pip/wheels/c9/97/49/1bf6b7b58d0adec650bcb625b6656877437d1f7d18c32e88ee
Successfully built riak basho-erlastic protobuf
Installing collected packages: six, basho-erlastic, protobuf, riak
Successfully installed basho-erlastic-2.1.1 protobuf-2.6.1 riak-2.5.2 six-1.10.0

[yassersouri]

It was inside a docker. @tahajahangir will provide more info for you.

[tahajahangir]

In side docker (an image derived from official debian-jessie image), the locale.getpreferredencoding() returns ANSI_X3.4-1968 (which is used as default encoding for open).

We set LC_TYPE=C.UTF-8 environment variable as a workaround for this issue.

[yassersouri]

Also it was on python 3.5

[lukebakken]

Thanks for that information, that helps a lot.

[lukebakken]

@tahajahangir @yassersouri - do you have any of these environment variables exported as well? (docs)

• LANGUAGE
• LC_ALL
• LC_CTYPE
• LANG

Interestingly enough, LC_TYPE isn't in that list.

[tahajahangir]

I've misspelled LC_TYPE, we set the correct LC_CTYPE var to C.UTF-8. Except the explicitly set LC_CTYPE variable, all other variables are not set (LANG, LANGUAGE, LC_ALL, LC_*).

The issue is also occurs with LC_CTYPE=C.

[lukebakken]

Thanks again. @tahajahangir - that explains why I did not see the issue. Arch Linux sets just about every environment variable related to character encoding to UTF-8:

$ declare -x|fgrep -i utf
declare -x LANG="en_US.UTF-8"
declare -x LC_ADDRESS="en_US.UTF-8"
declare -x LC_COLLATE="en_US.UTF-8"
declare -x LC_CTYPE="en_US.UTF-8"
declare -x LC_IDENTIFICATION="en_US.UTF-8"
declare -x LC_MEASUREMENT="en_US.UTF-8"
declare -x LC_MESSAGES="en_US.UTF-8"
declare -x LC_MONETARY="en_US.UTF-8"
declare -x LC_NAME="en_US.UTF-8"
declare -x LC_NUMERIC="en_US.UTF-8"
declare -x LC_PAPER="en_US.UTF-8"
declare -x LC_TELEPHONE="en_US.UTF-8"
declare -x LC_TIME="en_US.UTF-8"

I will modify the release process to ensure these variables are either unset or set to C to simulate other environments.