Push python wheels

[cjw85]

Apologies @Martinsos for creating an issue, but I didn't know how else to contact you.

The Travis infrastructure we put in to build python wheels requires a tag to be made. So at the moment there are no wheels on PyPI. Do you think you could made a new tag so that the wheels are pushed?

[Martinsos]

No problem @cjw85 , thanks for reminding me, can't believe I forgot this! I did necessary changes, now I am just waiting for Travis to build it - for some reason wait times became very long recently, maybe due to changes they did with plans, I am not sure. I will close the issue once this succeeds.

[Martinsos]

@cjw85 the wheels are up there! However, I see that they all have macosx in the name -> meaning they are not for linux, right? I then took a loot at our .travis.yml and I see that there is this line CIBW_SKIP="cp27-* pp* *-manylinux_i686", I am guessing this is the cause that we are not building any linux wheels? I missed that when merging the PR -> is there any specific reason for this, shouldn't we also add linux wheels?

[cjw85]

Skipping i686 is to ignore 32 bit wheels. There should still be 64bit (manylinux_x86_64) wheels. It looks to me like the whole linux job was skipped or died, since there's also no source distribution on PyPI, which is created and pushed from the linux job.

[Martinsos]

You are right, it seems the Linux job hasn't done its job (hoho).

I didn't realize something is wrong because it didn't fail in Travis.

First it errors with /home/travis/.travis/functions: line 110: cd: bindings/python: No such file or directory -> I guess I am already in bindings/python? I have to fix that line.

But then it continue and it dies kind of in a weird way, with the output below, while the whole job is reported as a success, which sucks.

I have to figure out how to make the whole job fail if this happens, and then also fix the error. Maybe fixing the wrong cd will be enough.

ERROR: After October 2020 you may experience errors when installing or updating packages. This is because pip will change the way that it resolves dependency conflicts.

We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default.

keyring 21.5.0 requires importlib-metadata>=1; python_version < "3.8", but you'll have importlib-metadata 0.18 which is incompatible.

Successfully installed Pygments-2.7.2 SecretStorage-3.2.0 bleach-3.2.1 cffi-1.14.3 chardet-3.0.4 colorama-0.4.4 cryptography-3.2.1 docutils-0.16 idna-2.10 jeepney-0.4.3 keyring-21.5.0 pkginfo-1.6.1 pycparser-2.20 readme-renderer-28.0 requests-2.24.0 requests-toolbelt-0.9.1 rfc3986-1.4.0 tqdm-4.51.0 twine-3.2.0 urllib3-1.25.11 webencodings-0.5.1

Traceback (most recent call last):

  File "/opt/python/3.6.7/lib/python3.6/runpy.py", line 193, in _run_module_as_main

    "__main__", mod_spec)

  File "/opt/python/3.6.7/lib/python3.6/runpy.py", line 85, in _run_code

    exec(code, run_globals)

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/twine/__main__.py", line 53, in <module>

    sys.exit(main())

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/twine/__main__.py", line 28, in main

    result = cli.dispatch(sys.argv[1:])

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/twine/cli.py", line 80, in dispatch

    main = registered_commands[args.command].load()

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2460, in load

    self.require(*args, **kwargs)

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2483, in require

    items = working_set.resolve(reqs, env, installer, extras=self.extras)

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pkg_resources/__init__.py", line 791, in resolve

    raise VersionConflict(dist, req).with_context(dependent_req)

pkg_resources.ContextualVersionConflict: (importlib-metadata 0.18 (/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages), Requirement.parse('importlib-metadata>=1; python_version < "3.8"'), {'keyring'})

Traceback (most recent call last):

  File "/opt/python/3.6.7/lib/python3.6/runpy.py", line 193, in _run_module_as_main

    "__main__", mod_spec)

  File "/opt/python/3.6.7/lib/python3.6/runpy.py", line 85, in _run_code

    exec(code, run_globals)

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/twine/__main__.py", line 53, in <module>

    sys.exit(main())

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/twine/__main__.py", line 28, in main

    result = cli.dispatch(sys.argv[1:])

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/twine/cli.py", line 80, in dispatch

    main = registered_commands[args.command].load()

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2460, in load

    self.require(*args, **kwargs)

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2483, in require

    items = working_set.resolve(reqs, env, installer, extras=self.extras)

  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pkg_resources/__init__.py", line 791, in resolve

    raise VersionConflict(dist, req).with_context(dependent_req)

pkg_resources.ContextualVersionConflict: (importlib-metadata 0.18 (/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages), Requirement.parse('importlib-metadata>=1; python_version < "3.8"'), {'keyring'})

[Martinsos]

OK, I just learned that after_success in Travis does not fail if commands in it fail, that is expected behaviour (wasn't so expected to me though!), so I moved deployment logic into script. I also removed that cd, it was redundant.

I will continue testing with this until I get it to work.

[Martinsos]

So the error happening is:

keyring 21.5.0 requires importlib-metadata>=1; python_version < "3.8", but you'll have importlib-metadata 0.18 which is incompatible.

It seems this is a new problem that appeared just couple of days ago, people have been talking about it here: https://travis-ci.community/t/cant-deploy-to-pypi-anymore-pkg-resources-contextualversionconflict-importlib-metadata-0-18/10494/4

Unfortunately, solution they provided is for case when using their deploy step, and I don't know what is actually causing this dependency clash. Since it takes 1h on Travis currently to get a build done, testing anything on it is more or less infeasible for me. I asked them for clarification, and I also tried solution with setting keyring to 21.4.0, let's see if that works.

[Martinsos]

I got the answer, fix is here: https://github.com/travis-ci/dpl/pull/1221/files . I tried applying the "upgrade eager" change so let's see once the build finishes!

[Martinsos]

Also, it seems that slow build are caused by Edlib being on travis .org, we have to migrate it to travis .com and it should help. I have to look in to that, possibly I will have to reencrypt secrets and update badges.

[Martinsos]

All right, this should be it now! Wheels are uploaded, and uploading works. I will create a separate issue for migrating to travis .com. @cjw85 let me know if all is not ok.