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](https://github.com/tox-dev/tox/issues/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](https://github.com/HypothesisWorks/hypothesis/issues/2367#issuecomment-595524571)
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.
I only had the old way save in my bash history and this one was only
mentioned in the changelog.
Also changed the heading above the new entry to be title case, which
seems to be more consistent with the other headinfs in the file.
Also remove the one remaining mention of `QUTE_BDD_WEBENGINE` since it
does nothing anymore.
Commits for dropping 3.5 support to copy from:
c245b7d855ccd "Initial drop of Python 3.5"
ccdfb44b85 "Drop support for Python 3.6.0"
Anything needed to update regarding OS version support in
doc/install.asciidoc?
TODO: remove 3.6/7 annotations in requirements files and
rebuild
workflows: not sure I updated it right (run 5.12 with 3.7, same 18.04 OS) but
18.04 seems to have 3.7 on it too so it should work. It'll all change when we
drop <5.15 anyway. Not sure what the minimum ubuntu version will be going
forward.
Regarding mimetype overrides (ebb3046822) the doctring says they can all go
in 3.7 but .h5 is still missing on py39, not sure if we should care.
There are a bunch of old(?) warning messages still ignored in tests/end2end/fixtures/quteprocess.py.
Florian Bruhin
Jun Chen
toofar
Philipp Albrecht
Jimmy
Jethro Cao
arza