search

galaxy-iuc / parsec

Access Galaxy at the speed of light with automatically generated BioBlend wrappers
Apache License 2.0
9 stars 9 forks source link

Object of type bytes is not JSON serializable #30

Closed pvanheus closed 4 years ago

pvanheus commented 4 years ago

This happens when I try and download a dataset from our (Galaxy 19.05) server. Please let me know what further info will help debug this.

Full trace: 

$ parsec datasets download_dataset --use_default_filename 10f30d1bb6a74032
Traceback (most recent call last):
  File "/usr/people/pvh/miniconda3/envs/galaxy-parsec/lib/python3.7/site-packages/parsec/decorators.py", line 18, in custom_exception
    return wrapped(*args, **kwargs)
  File "/usr/people/pvh/miniconda3/envs/galaxy-parsec/lib/python3.7/site-packages/parsec/decorators.py", line 43, in dict_output
    print((json.dumps(output, indent=4)))
  File "/usr/people/pvh/miniconda3/envs/galaxy-parsec/lib/python3.7/json/__init__.py", line 238, in dumps
    **kw).encode(obj)
  File "/usr/people/pvh/miniconda3/envs/galaxy-parsec/lib/python3.7/json/encoder.py", line 201, in encode
    chunks = list(chunks)
  File "/usr/people/pvh/miniconda3/envs/galaxy-parsec/lib/python3.7/json/encoder.py", line 438, in _iterencode
    o = _default(o)
  File "/usr/people/pvh/miniconda3/envs/galaxy-parsec/lib/python3.7/json/encoder.py", line 179, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type bytes is not JSON serializable

Object of type bytes is not JSON serializable

The corresponding Galaxy log is:

192.168.2.35 - - [02/Feb/2020:19:13:28 +0200] "GET /api/datasets/10f30d1bb6a74032?hda_ldda=hda&key=cad530347a2f9cf38235f0d220738b8a HTTP/1.1" 200 - "-" "python-requests/2.22.0"
[pid: 5530|app: 0|req: 5646/5646] 192.168.2.35 () {38 vars in 601 bytes} [Sun Feb  2 19:13:28 2020] GET /api/datasets/10f30d1bb6a74032?hda_ldda=hda&key=cad530347a2f9cf38235f0d220738b8a => generated 102120 bytes in 118 msecs (HTTP/1.1 200) 3 headers in 139 bytes (1 switches on core 0)
192.168.2.35 - - [02/Feb/2020:19:13:28 +0200] "GET /api/histories/7b668ee810f6cf46/contents/10f30d1bb6a74032/display?to_ext=vcf&key=cad530347a2f9cf38235f0d220738b8a HTTP/1.1" 200 103288 "-" "python-requests/2.22.0"
[pid: 5530|app: 0|req: 5647/5647] 192.168.2.35 () {38 vars in 667 bytes} [Sun Feb  2 19:13:28 2020] GET /api/histories/7b668ee810f6cf46/contents/10f30d1bb6a74032/display?to_ext=vcf&key=cad530347a2f9cf38235f0d220738b8a => generated 0 bytes in 27 msecs (HTTP/1.1 200) 6 headers in 373 bytes (1 switches on core 2)
hexylena commented 4 years ago

So that command has a bunch of flags that never really worked as well as they should for such a central operation. One option:

(.venv) [hxr@mk:/tmp/tmp.AIix3OAOIa]1$ parsec --verbose datasets download_dataset 11ac94870d0bb33aadffe0eeb5bf4a3b --file_path .

and it will write to the current directory with the default filename. There isn't really a good way to override use_default_filename, and that command probably needs to have a special exception written into the auto-extraction process to ignore that flag because it just causes issues.