Tips for contributors to run the webkit backend #8158
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The dependancy update job was complaining about something webkit only, and I wanted to be able to check if I broke stuff locally. So I had a crack at getting something setup locally based on the webkit docker container used for CI and took some notes for myself for next time. Let me know if there is a better way to acheive this!
My virtualenv I used to run webkit has rotted long ago and I don't remember how I set it up. There is a PyQtWebKit project on PyPI but I don't know who that's published by.
So I figured I would write some notes for myself on using the docker container used for CI instead. I chose to mount the current directory (which is presumably a qutebrowser checkout!) directly into the container instead of cloning it so I could have quicker feedback between making code changes and running tests.
Then there's a couple of things that stem from that. Since the user in the container is different from the one in the host we have to move some things that are normally written to the current directory to be written elsewhere. There are other ways to approach this (eg you can add
-u $(id -u)
to the docker command line, although that makes things a bit confusing in the container) but arguably it's good for the container not to be able to write to the host, hence making that volume read only.The TOX_WORK_DIR trick is from
here, except with
{toxinidir}
in it too because the pyroma env was failing with just.tox
, saying the pyroma binary needed to be in the allowlist, possibly it was doing full path matching without normalizing. The hypothesis folkshere say if you want to override the examples DB location with an env var to do it yourself. It's actually only a warning from hypothesis, it says it falls back to an in-memory DB, but I guess the tests run with warnings-are-errors. You can also pass
database=None
to make hypothesis skip example storage altogether.I'm using tox to run commands in a virtualenv with the right stuff in it because, uh, because I was copying the CI workflow actually. I just found out about the
exec
subcommand to override thecommands
defined for the env, neat! One point of awkwardness about that this is that since we are using the PyQt from the OS we need any virtualenv to have access to the OS packages, which isn't the default for tox. The text envs use the link_pyqt script for that but if you are using this container and the first thing you do is runtox exec
then that wouldn't have been run. So I'm settingVIRTUALENV_SYSTEM_SITE_PACKAGES
to tell tox to always make the system packages available in the virtualenvs it manages.I did try using the mkvenv script instead of tox but it complained when trying to install the current directory in editable mode because setup.py tries to write to a git-commit-id file.