Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tips for contributors to run the webkit backend #8158

Merged
merged 1 commit into from
Jun 23, 2024
Merged

Commits on Jun 23, 2024

  1. Tips for contributors to run the webkit backend

    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](tox-dev/tox#20), apart from 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 folks
    [here](HypothesisWorks/hypothesis#2367 (comment))
    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 the `commands` defined for the env,
    neat! One point of awkwardness about that is that since we are using the
    PyQt from the OS we need any virtualenv we use to have access to the OS
    packages, which isn't the default for virtualenvs created by 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 run `tox exec` then that
    wouldn't have been run. So I'm setting `VIRTUALENV_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.
    toofar committed Jun 23, 2024
    Configuration menu
    Copy the full SHA
    d0422a9 View commit details
    Browse the repository at this point in the history