Since Archlinux upgraded to Python 3.11, we need to downgrade Python
to 3.10 too, and install tox via pip instead.
This starts becoming somewhat questionable, but if this approach still
does indeed work, let's go for it.
Although we updated the tox requirements files for tox4 in December, it
looks like the docker containers (or at least the one(s) that call this
script) are still using tox3. `.tox-config1` isn't written anymore with
tox4 (although my git-fu isn't strong enough to find the commit that
removed it).
The "Rebuild Docker CI images" run 912 was the last to have tox 3.26.0-2
and run 913 had version 4.4.12-1.
I'm not sure the new change does the same thing as whatever the old code
did. I honestly have no idea why we can't just follow the python symlink
and have to go to a config file. In what case does the python binary not
link to the system one?
In addition to this `.tox-info.json` file there is also the more
standard `pyvenv.cfg` file. I would prefer to use that over the tox
thing as generally I find tox to be a high barrier of entry for
contributors. But in that case the pyvenv one doesn't seem to be well
documented either...
Anyway, if anyone knows any cases where following the symlink of the
python in the venv isn't reliable that would be great. Because that
seems like the simpler method.
Pin Flask and Werkzeug for py3.7
They've removed compatibility upstream.
Added example to readme file because I had to go dig for one in the
commit history.
Add blinker to changelog URLs as it's a required dependency of Flask
now.
Looks like we have some failing smoke tests with:
[6636:16643:0329/041427.206197:ERROR:command_buffer_proxy_impl.cc(141)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
On CI were were getting "Could not import sip" because link_pyqt was
looking for PyQt5.sip.
I made that look at QUTE_QT_WRAPPER since that's being set already on
tox.ini
There are probably a few other changes around link_pyqt and the makefile
etc we need to change when we switch the default wrapper.
I overrode the default `py` tox environment with py-qt6 to override
those wrapper related variables. I probably could have done something
sneaky with curly braces to make it so we don't have to add a few more
lines to the file. But in my opinion in config file is far to obfuscated
and hard to maintain already.
I changed the docker file to call the new py-qt6 env if it's a qt6
container. I'm not 100% sure that is required though since there is also
a tox invocation in the GH action definition, maybe that overrides the
container entrypoint? Also changed the indentation in the dockerfile
template a bit to make it easier to see where the conditionals start and
end.
Speaking of which I changed the matrix definition and tox invocation to
match a later one to hopefully make it so we can invoke different tox
environments in the containers without having to rebuild the containers.
Not sure I did that right, I'll see soon.
I added the unstable-qt6 container generation line so we can use it in
the future, and to match the not-qt6 one. I'm not switching to that in
CI though because the pyqt used by that is broken at the moment
(ref https://www.riverbankcomputing.com/pipermail/pyqt/2023-March/045214.html)
Also fixed the vim modeline in generate.py so my syntax highlighting
works.
In doc/help/index.asciidoc, we have links like this:
* link:../quickstart{outfilesuffix}[Quick start guide]
That is correct in e.g. the GitHub file structure, as those files are
stored in e.g. doc/quickstart.asciidoc indeed.
It's *no* longer true when we view the built files via qute://help,
however: There, this turns into a flat file structure, with those pages
being at qute://help/index.html and qute://help/quickstart.html,
respectively.
It looks like QtWebEngine < 6.5 did just ignore the
<a href="../quicktart.html"> and pointed from qute://help/index.html to
qute://help/quickstart.html anyways, weirdly.
With QtWebEngine 6.5, however, this is now interpreted as a link
pointing to qute://quickstart.html instead, which is clearly wrong.
Until we have a less messy doc generation (probably as part of #345),
let's just patch the link to be correct.
See #7624
Mostly pretty lazy fixes. Most of the places in the tests we were
already matching on error message, a couple of places we weren't. The
tick-tock one was the only one that wasn't being used right where it was
raised.
Some of them I just changed to RuntimeError because it was shorter than
adding the pylint directive.
This is actually the renamed pep517, but I'm not removing that as
pyorama still depends on it. Even though pyproject_hooks got added to
the pyorama requirements file, huh???
This fails now with 'failed with env name pyinstaller-32 conflicting with base python C:\hostedtoolcache\windows\Python\3.10.9\x86\python.exe'
See https://github.com/tox-dev/tox/pull/2824
Florian Bruhin
toofar