ESGF / esgf-prepare

Toolbox preparing your data for ESGF publication
http://esgf.github.io/esgf-prepare/
2 stars 7 forks source link

unicode ascii conversion error in "esgprep drs tree" #12

Closed alaniwi closed 6 years ago

alaniwi commented 6 years ago

I can't get "esgprep drs tree" to work because of:

    main.run(args)
  File "/path/to/esgf-prepare/esgprep/drs/main.py", line 177, in run
    getattr(ctx.tree, ctx.action)()
  File "/path/to/esgf-prepare/esgprep/drs/handler.py", line 464, in tree
    self.show()
  File "/path/to/treelib/tree.py", line 658, in show
    print(self._reader)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 9-11: ordinal not in range(128)

I haven't understood the code well enough to know what string it was trying to convert, but I am not aware of any non-ascii characters in the input that I'm using.

glevava commented 6 years ago

This errors comes from the "treelib" library. Probably an encoding issue. I have to investigate on it, ascii options are available from the lib. Come back to you for testing, because I never get this error during my tests

glevava commented 6 years ago

I had a look on the treelib library, since 1.5 version the Python 3 support impacts the unicode statements (see documentation). Following the latest treelib commits, I recommend to only use the 1.4.0. I already modified the esgprep requirements. Can you try again by installing pip install treelib==1.4.0 before?

alaniwi commented 6 years ago

Sorry, only just noticed this question. I forget exactly where things got to in the discussion on Slack, but anyway, I can confirm that it works in an existing virtual environment that includes treelib 1.4.0, although I don't remember the order of installation of packages in that environment.

The output includes some characters that do not display correctly in all terminals (e.g. "└──") but that is not very important. (Maybe I implied incorrectly in the earlier discussion on Slack that the output was different in different terminals. No, it always produces the same characters, but they depend on Unicode support in order to display correctly.)

Probably this ticket can be closed.