update-cb3 fails when url is .exe

update-cb3 fails on otlm-feedstock with

Traceback (most recent call last):
  File "/root/repo/cf-scripts/conda_forge_tick/auto_tick.xsh", line 170, in main
    hash_type=attrs.get('hash_type', 'sha256'))
  File "/root/repo/cf-scripts/conda_forge_tick/auto_tick.xsh", line 87, in run
    migrate_return = migrator.migrate(recipe_dir, attrs, **kwargs)
  File "/root/repo/cf-scripts/conda_forge_tick/migrators.xsh", line 366, in migrate
    content, self.messages = update_cb3('meta.yaml', self.cfp)
  File "/opt/conda/lib/python3.6/site-packages/conda_smithy/update_cb3.py", line 184, in update_cb3
    need_f, need_c, need_cxx, need_numpy_pin = get_compilers(url)
  File "/opt/conda/lib/python3.6/site-packages/conda_smithy/update_cb3.py", line 116, in get_compilers
    with tarzip_open(os.path.join(tmp_dir, fname)) as tf:
  File "/opt/conda/lib/python3.6/tarfile.py", line 1574, in open
    raise ReadError("file could not be opened successfully")
tarfile.ReadError: file could not be opened successfully

This is happening because the url is .exe, but it is trying to be read as a tarfile.

otlm-feedstock actually does have a tar.gz url, but I think update-cb3 just uses the last url in the meta.yaml, which is .exe here.

[ocefpaf]

Done in https://github.com/conda-forge/otlm-feedstock/pull/8

@justcalamari if you find more just ping me directly I’ll fix them. That way we can reduce the noise and make progress quicker.

[isuruf]

Agree with @ocefpaf, I never meant this code to be maintainable. It’s terrible code that I wrote a few months back in a Hackathon in the middle of the night.