| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts commit 6c4be8ef03bdcf09e86e14de02b8bd308e6e527b.
Possibly easier solution in next commit.
|
|
See https://www.riverbankcomputing.com/pipermail/pyqt/2024-April/045832.html and https://github.com/pypi/support/issues/3949
|
|
6.7 is released now, some distros are already shipping it!
This commit:
1. adds a new 6.7 requirements file (the plain 6 one has already been
updated by the bot)
2. adds a new tox env referring to the new requirements file
3. updates the mac and windows installer jobs to run with pyqt67 with the
assumption we'll be including that in our next release
4. adds two new CI environments for 6.7, one each for python 3.11 and 3.12
(3.12 only came out like 6 months ago)
5. updates a couple of references to the py37 tox env that looked like they
were missed, 3.7 support was dropped in 93c7fdd
6. updates various ubuntu containers to the latest LTS instead of the previous
related one - this is quite unrelated to this change but I thought I would
give it a go, no need to use the old one unless we are specifically testing
on it?
- linters - they use tox but probably use system libraries
- these all run in nested containers anyway, should be fully isolated
- codeql - eh, uses a third party action, check the docs if it fails
- irc - as above
|
|
|
|
|
|
Right now, the Riverbank PyPI server has a PyQt5 sdist but no wheels.
|
|
Reverts 0b0401f8bb23fa57bac13e14b522c9755cba05f7
Fixed in virtualenv 20.23.0 which ships pip 23.1.2 which ships setuptools
67.7.2.
Archlinux upgraded finally in August:
https://gitlab.archlinux.org/archlinux/packaging/packages/python-virtualenv/-/commits/main
|
|
What is that big chain of !pyqt- etc mean? idk
ref: https://github.com/qutebrowser/qutebrowser/pull/7990
|
|
This reverts commit 6042fccbf58955dba251e833d3ed4d66d79102e9.
|
|
This should make pip fall back to PyPI for packages not on Riverbank's server
|
|
See #3725
|
|
|
|
|
|
|
|
|
|
|
|
feat/mac_sandbox_pre_release_pyinstaller
Only conflict was the removal of support for 32bit builds in
build_release.py
|
|
Run package building on CI with warnings turned into errors
|
|
We got a `DeprecationWarning` during the package build, which we were not able to
reproduce locally. For now we just don't turn this particular `DeprecationWarning` into
an exception to not fail CI.
|
|
This is still *very* basic, but it serves its purpose of failing for warnings during
package build.
I verified that `tox -e package` is failing by introducing some warnings with this change:
```diff
diff --git a/setup.py b/setup.py
index feb949595..6810eaf1e 100755
--- a/setup.py
+++ b/setup.py
@@ -51,8 +51,7 @@ def _get_constant(name):
try:
common.write_git_file()
setuptools.setup(
- packages=setuptools.find_namespace_packages(include=['qutebrowser',
- 'qutebrowser.*']),
+ packages=setuptools.find_namespace_packages(include=['qutebrowser']),
include_package_data=True,
entry_points={'gui_scripts':
['qutebrowser = qutebrowser.qutebrowser:main']},
```
|
|
See #6050, still keeping open to track NSIS changes
|
|
Since we are pulling down PyInstaller off of the develop branch we need
to recompile the bootloader, because upstream only commits a new one
back to the branch on releases. Luckily all the compiler requirements
seem to already be installed on CI.
For the record the macOS CI is currently failing with
dlopen: dlopen(/Users/runner/work/qutebrowser/qutebrowser/dist/qutebrowser.app/Contents/MacOS/libpython3.10.dylib, 10): image not found
And upon inspection of dist/ that file seems to be at
./qutebrowser.app/Contents/Resources/libpython3.10.dylib
./qutebrowser.app/Contents/Frameworks/libpython3.10.dylib
./qutebrowser/_internal/libpython3.10.dylib
|
|
6.5.2 is out with the fixes in
|
|
Closes #7097
|
|
|
|
|
|
They are getting much better
|
|
|
|
|
|
|
|
Only mypy missing now...
|
|
|
|
|
|
Otherwise we run into a Python 3.12 incompatibility with pkg_resources:
https://github.com/pypa/pip/issues/11501
Also needs PIP_REQUIRE_VIRTUALENV=0 because otherwise pip seems to
falsely assume it's installing things system-wide, weirdly.
Should probably be removed once there is a newer virtualenv, which
vendors a newer pip, which vendors a newer pkg_resources...
See #7727
|
|
- Make sure we still test Python 3.7 and 3.8 after dropping old PyQt
versions in c5a51eb0bcbab0b68cdfbf3eba2e681cff2adf7a
- Keep a modern Python version (3.11) with Qt 5 around, however
- Make sure we still test Python 3.10 too
- Also start testing the Python 3.12 alpha
|
|
See #7624
|
|
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.
|
|
|
|
Needed so that tests generating :help docs run properly.
Follow-up to af176f749fd7f5521d3978e268a1fad169ac2bd4 and
bbdc83f638ed1a8e263a3efac0da8a901c1a1420
(cherry picked from commit 3d56f57e502ffaad40936f19f44083a2b63f0690)
|
|
Needed so that tests generating :help docs run properly.
Follow-up to af176f749fd7f5521d3978e268a1fad169ac2bd4 and
bbdc83f638ed1a8e263a3efac0da8a901c1a1420
|
|
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
|
|
|
|
|
|
|
|
|
|
See https://tox.wiki/en/4.0.3/faq.html#tox-4-changed-ini-rules
|
|
|
|
also update the default tox env list which I forgot to do when changing
the mypy targets.
|
|
(Ab)using an environment variable indeed seems like the easiest way
forward here, but since it is exposed in the environment for the called
processes, let's give it a name which is less likely to clash, and more
easily identifyable.
Follow-up to c1738ca55006966e7c0ad9eacbfb58625aa88c44.
|
