search

ionelmc / cookiecutter-pylibrary

Enhanced cookiecutter template for Python libraries.
BSD 2-Clause "Simplified" License
1.25k stars 207 forks source link

Travis build fails on every case with non-default pyproject.toml #206

Closed dHannasch closed 4 years ago

dHannasch commented 4 years ago

Aha! I've figured out what all the failing builds have in common: something extra included in pyproject.toml build-system.requires, whether it's cffi or setuptools_scm. Whenever either of those is present, the build fails with pip._vendor.pep517.wrappers.BackendUnavailable. Possibly because it's trying and failing to install either cffi or setuptools_scm and finding it doesn't have infrastructure to install packages (whereas setuptools and wheel are fine because they're already present).

https://pip.pypa.io/en/stable/reference/pip/#pep-517-and-518-support

https://github.com/ionelmc/cookiecutter-pylibrary/pull/204 was supposed to fix this, but it doesn't.

ionelmc commented 4 years ago

Can I reproduce this locally? Or do you have some logs I can look at?

dHannasch commented 4 years ago

Can I reproduce this locally? Or do you have some logs I can look at?

See e.g. https://github.com/ionelmc/cookiecutter-pylibrary/pull/169. Any pull request with no changes will fail on Travis on ENVs cffi, separate-cffi, separate-cext-scm-osx-publish, separate-cffi-scm-osx-publish, and separate-cython-scm-osx-publish.

https://github.com/ionelmc/cookiecutter-pylibrary/pull/207 fixes this by way of disabling PEP517 for PyPy.

It appears that PEP517 does not currently work with PyPy: https://github.com/pypa/pep517/issues/74

ionelmc commented 4 years ago

Note that https://travis-ci.org/github/ionelmc/cookiecutter-pylibrary/builds/738309529 doesn't appear to have the problem. Am I missing something here?

ionelmc commented 4 years ago

I added this change and CI still passes https://travis-ci.org/github/ionelmc/cookiecutter-pylibrary/builds/738321966

Could it be that travis had some old virtualenv/pip/setuptools that had some issues that produced that BackendUnavailable situation?

Regardless, I would try really hard to not bake in too many workarounds into the packaging metadata, and rather have the workarounds in the testing/ci configuration (since that's what causes problems in the first place). Eg: if travis has broken system packages work around that by upgrading them in travis.yml or installing them in tox.ini (specifying setuptools_scm or whatever).

dHannasch commented 4 years ago

Note that https://travis-ci.org/github/ionelmc/cookiecutter-pylibrary/builds/738309529 doesn't appear to have the problem. Am I missing something here?

https://travis-ci.org/github/ionelmc/cookiecutter-pylibrary/builds/738309529 didn't actually run the tox tests, and therefore, it never actually attempted to install the cookiecut package. When Travis runs on master, it retrieves the credentials for https://github.com/ionelmc/python-nameless and pushes to https://github.com/ionelmc/python-nameless. When Travis runs on a pull request, it cannot retrieve the credentials, so it runs tox locally, which fails if it cannot install the cookiecut package. If you look at the python-nameless build corresponding to that build, which actually does run tox, you can see --- you can see --- https://travis-ci.org/github/ionelmc/python-nameless/builds/738461660 --- that it --- passes?

I had assumed that https://github.com/ionelmc/python-nameless builds corresponding to those options were also failing. But they're not. That's...weird. What's different? Nothing seems obviously different in the setup between https://github.com/ionelmc/python-nameless/blob/test-cffi/.travis.yml and https://github.com/ionelmc/cookiecutter-pylibrary/blob/master/.travis.yml.

Could it be that travis had some old virtualenv/pip/setuptools that had some issues that produced that BackendUnavailable situation?

On the one hand, given that python-nameless is passing, clearly PyPy does in fact work with PEP517. On the other hand, we're talking about Travis in both cases, and it isn't obvious what's different between the .travis.yml files.

https://github.com/ionelmc/cookiecutter-pylibrary/pull/208 is attempting to mimic the matrix structure of the cookiecut package.

ionelmc commented 4 years ago

Oh damn I forgot about that PR thing. Well ... in python-nameless's CI the tests run on bionic, while cookiecutter CI still has xenial. I guess you could try upgrading to bionic (we have to upgrade at some point anyway) and hope the problems go away?

dHannasch commented 4 years ago

in python-nameless's CI the tests run on bionic, while cookiecutter CI still has xenial.

In the linked passing build, python-nameless is running on Xenial too.

I think it might come down to specifying 'python' for Travis. python-nameless specifies individual Python versions for each. Intuitively it makes sense that if we don't specify python: pypy3 then we get BackendUnavailable. I'm trying to mimic the python-nameless matrix in https://github.com/ionelmc/cookiecutter-pylibrary/pull/208 but there must be some problem with the syntax somewhere because it's only running a single build. It's weird. I keep making it more and more elaborate, down to mimicking the exact indentation, but it still acts differently from the python-nameless .travis.yml.

dHannasch commented 4 years ago

https://github.com/ionelmc/cookiecutter-pylibrary/pull/208 now successfully runs Travis with PyPy3 as the Python version...but pypy3 inst: /home/travis/build/ionelmc/cookiecutter-pylibrary/python-nameless/.tox/.tmp/package/1/nameless-1.0.0.zip still fails with pip._vendor.pep517.wrappers.BackendUnavailable.