Issues with latest release of `cffi`

[elParaguayo]

The cffi package was updated at the start of July and caused CI failures for qtile.

With the help of the cairocffi team, I was pointed to this stackoverflow post.

I've tried to make that change in the tox environment in CI but I'm now getting this error:

error: cffi 1.15.1 is installed but cffi==1.15.0 is required by {'xcffib'}

I can't see anywhere where that requirement is being set so I'm a bit confused as to how to fix it.

Any ideas?

[tych0]

Do you have a link to a failed job, and can you show the patch you added? I poked through the PRs and didn't see anything obvious in those failures, and git master looks green.

My best guess is that it's the system cffi interacting with the pip cffi in some unfortunate way, which can generally be resolved by uninstalling the system cffi, but without seeing a failure it's hard to be sure.

One way to debug this would be to python3 -c 'import cffi; print(cffi.__file__); and see which cffi python is using.

[elParaguayo]

It's this PR: https://github.com/qtile/qtile/pull/3670

Failed job is here: https://github.com/qtile/qtile/runs/7362018528?check_suite_focus=true

[tych0]

Looks like it's some sort of awful interactions between what's on the host via github actions and what's in pip:

2022-07-15T17:06:33.7382699Z ##[group]tox: pypy3
2022-07-15T17:06:33.7383644Z pypy3 installdeps: pytest >= 6.2.1, pytest-cov >= 2.10.1, setuptools >= 40.5.0, bowler, xkbcommon >= 0.3, pywayland >= 0.4.12, dbus-next, PyGObject
2022-07-15T17:07:23.0848740Z pypy3 installed: appdirs==1.4.4,attrs==21.4.0,bowler==0.9.0,cffi==1.15.0,click==8.1.3,coverage==6.4.2,dbus-next==0.2.3,fissix==21.11.13,greenlet==0.4.13,hpy==0.0.3,importlib-metadata==4.12.0,iniconfig==1.1.1,moreorless==0.4.0,packaging==21.3,pluggy==1.0.0,py==1.11.0,pycairo==1.21.0,PyGObject==3.42.1,pyparsing==3.0.9,pytest==7.1.2,pytest-cov==3.0.0,pywayland==0.4.13,readline==6.2.4.1,tomli==2.0.1,typing_extensions==4.3.0,volatile==2.1.0,xkbcommon==0.4,zipp==3.8.1
2022-07-15T17:07:23.0856913Z pypy3 run-test-pre: PYTHONHASHSEED='938979667'
2022-07-15T17:07:23.0860979Z pypy3 run-test: commands[0] | pip install --force-reinstall --no-binary :all: cffi
2022-07-15T17:07:24.6630013Z Collecting cffi
2022-07-15T17:07:24.7350058Z   Downloading cffi-1.15.1.tar.gz (508 kB)
2022-07-15T17:07:24.7795805Z      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 508.5/508.5 kB 15.3 MB/s eta 0:00:00
2022-07-15T17:07:24.9360201Z   Preparing metadata (setup.py): started
2022-07-15T17:07:27.9153933Z   Preparing metadata (setup.py): finished with status 'done'
2022-07-15T17:07:27.9193607Z Skipping wheel build for cffi, due to binaries being disabled for it.
2022-07-15T17:07:28.3398590Z Installing collected packages: cffi
2022-07-15T17:07:28.3403179Z   Attempting uninstall: cffi
2022-07-15T17:07:28.3420310Z     Found existing installation: cffi 1.15.0
2022-07-15T17:07:28.3443608Z     Not uninstalling cffi at /opt/hostedtoolcache/PyPy/3.7.13/x64/lib_pypy, outside environment /home/runner/work/qtile/qtile/.tox/pypy3
2022-07-15T17:07:28.3453695Z     Can't uninstall 'cffi'. No files were found to uninstall.
2022-07-15T17:07:28.3547185Z   Running setup.py install for cffi: started
2022-07-15T17:07:31.6028471Z   Running setup.py install for cffi: finished with status 'done'
2022-07-15T17:07:31.6281869Z Successfully installed cffi-1.15.1

In particular, the bit about:

2022-07-15T17:07:28.3443608Z     Not uninstalling cffi at /opt/hostedtoolcache/PyPy/3.7.13/x64/lib_pypy, outside environment /home/runner/work/qtile/qtile/.tox/pypy3

then it silently continues, and pip3 is convinced that 1.15.1 is installed, but really it's 1.15.0, and everything is very confusing after that.

My recollection is that pypy is a little bit special in that it has a built-in version of cffi, instead of it being a separate wheel/package/whatever that's installed later:

/packages/qtile master pypy3
Python 3.8.13 (7.3.9+dfsg-1, Apr 01 2022, 21:41:47)
[PyPy 7.3.9 with GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>> import cffi
>>>> print(cffi.__file__)
/usr/lib/pypy3.8/cffi/__init__.py
>>>>
~/packages/qtile master python3
Python 3.10.4 (main, Jun 29 2022, 12:14:53) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cffi
>>> print(cffi.__file__)
/home/tycho/.local/lib/python3.10/site-packages/cffi/__init__.py
>>>

As a result I think you'll have to match exactly the version of pypy3's cffi (at least for pypy), since it cannot be changed. I suppose before this release they just lined up by coincidence, and now for some reason they don't. (Maybe this is a bug in pypy3's pip, where it should know about "system" packages and always assume the same version?)

You could figure out what this version is and do some magic to specify it during CI:

~/packages/qtile master pypy3
Python 3.8.13 (7.3.9+dfsg-1, Apr 01 2022, 21:41:47)
[PyPy 7.3.9 with GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>> import cffi
>>>> cffi.__version__
'1.15.0'

Maybe with a quick sed somewhere or something?

[tych0]

So I just tried https://github.com/tych0/qtile/runs/7365194120?check_suite_focus=true hardcoding the version to 0.15.0 to match the pypy3 version of cffi that's in the github actions runners, and that seems to be working. I guess that's fairly similar to what you already had, though, so maybe it's not an improvement (other than the comment describing where the version number comes from, perhaps).

[elParaguayo]

Interesting. So we could do:

    !pypy3: pip install --force-reinstall --no-binary :all: cffi
    pypy3: pip install cffi==1.15.0

That seems to be working at the moment: https://github.com/qtile/qtile/actions/runs/2679433320

[tych0]

Yep, I think so. There's some technical reason cffi has to be built in to pypy that I forget, but it is kind of painful in cases like this. I wonder if it's worth filing a bug with the pip people about it.

[elParaguayo]

Ok. Thanks for the help.