- Mar 28, 2025
-
-
Joris Lijssens authored
-
- Mar 24, 2025
-
-
muxator authored
This change uses GNU Make specific syntax, as per: https://www.gnu.org/software/make/manual/make.html#Canned-Recipes I have verified with one of the FreeBSD maintainers for TortoiseHg that this change would not impact packaging (this Makefile is for development only, and Ports are a totally independent project), and the developers' workflow (because it is common practice to use devel/gmake to work on upstream projects).
-
muxator authored
This was an oversight in the previous two commits: it should have been part of those.
-
muxator authored
The commands "make tests" and "make pytype" require that the user sets HGPATH. The Make syntax for doing it can be unintuitive for a non expert. This change extends the error message, introducing an example for a syntactically correct invocation, which also shows a possible actual value for HGPATH. EXAMPLE: $ make pytype HGPATH not specified. Please run again with 'make pytype HGPATH=/path/to/hg'. For example, you could point to a checkout of the mercurial source code make: *** [Makefile:46: pytype] Error 1
-
muxator authored
Before this change, if a user mistakenly set HGPATH to point to a file (for example, because he used <MERCURIAL_BASE>/hg/hg), he would receive the "HGPATH not found" error, which would be confusing. Now he would receive an explicit message that HGPATH needs to be a directory. This commit makes apparent some pre existing code duplication. For now I propose to live with that. There is the possibility of reducing it via a GNU-specific syntax (for example https://stackoverflow.com/questions/6783243/functions-in-makefiles/74742720). That will eventually be done in a dedicated patch at the end of the series.
-
muxator authored
-
- Mar 23, 2025
-
-
muxator authored
Commit cde4a42b1a2c ("blockmatcher: add type hints to four functions in BlockList. Fix a type error") introduced a type hint for QMouseEvent without importing it. This was an error on my part. Caught by Pytype in CI.
-
- Mar 20, 2025
-
- Mar 18, 2025
-
-
muxator authored
This commit adds type hints to the four functions that are involved in a Qt6 crash detailed in #6023. In the process it becomes evident a type mismatch that always existed. The commit also fixes that one. This is the mismatch: scrollToPos() called setValue() with a float value. setValue() in turn emitted the pyqtSignal(int) valueChanged, but passing the float value instead. This was fine in Qt5, but would break in Qt6. This commit puts in place the type hints and rounds to int "value" as a preventive measure, that stays compatible with Qt5, and would not break under Qt6. The final fix for the crash will be put in place in the next commit.
-
- Mar 05, 2025
-
-
Matt Harbison authored
Mercurial no longer supports direct invocation of `setup.py`, and `make local` isn't equivalent to what was previously done. The easiest workaround is to pip-install from source into the venv. I considered installing the wheel, but I'd rather not manually manage the version used via commits. Additionally, rc wheels aren't installed from PyPI by default. I also tried an editable install, but py2app wasn't able to find `hgext` or `mercurial`.
-
- Feb 22, 2025
-
-
Matt Harbison authored
The one thing we're missing here is the generated index for the extensions help. That needs to be fixed in the hg build process, but there's also a bug since hg 843418dc0b1b (March 2020) that seems to cause the index to be ignored by py2exe altogether. So let's not worry about that for now. There are also a few missing/added python packages by way of diffing `library.zip` against the 6.9 installation, but they seem harmless. The macOS installer still needs to be done.
-
- Feb 21, 2025
-
-
Matt Harbison authored
This dependency was removed in hg 7.0.
-
- Mar 01, 2025
-
-
Matt Harbison authored
This isn't the latest version, but the release notes for 0.12.0 talk about new APIs and deprecating `setup.py py2exe`. That probably means overhauling both `setup.py` like was done for Mercurial this cycle, as well as the packaging code. Let's kick that can down the road. In the meantime, this picks up important fixes like `sys.std{out,err}.write()` returning the number of bytes written (per python3) instead of None.
-
- Dec 26, 2024
-
-
Matt Harbison authored
We've switched to this in core hg, and there have definitely been scenarios where the `pycompat` variable didn't evaluate as expected.
-
- Feb 28, 2025
-
-
Matt Harbison authored
Strings are unicode on Python 3. These were rewritten by `pyupgrade`. See hg 9db77d46de79.
-
Matt Harbison authored
PEP-3120[1] (Python 3.0 in 2007) says that UTF-8 is the default encoding. That should be long enough ago that no reasonable editor would trip over this, and certainly any supported version of Python won't. `msgfmt.py` was already UTF-8 formatted. See hg f19a3f1437f3. The comments were probably harmless, but as `pyupgrade` has no mechanism to disable this change, omitting this change makes it unusable as a code checking tool, and makes it a pain to use occasionally to upgrade the source (since these changes would need to be manually reverted). [1] https://peps.python.org/pep-3120/
-
- Feb 27, 2025
-
-
Matt Harbison authored
This is the `fstrings` fixer in `pyupgrade`. See hg 5027ae0d89b3.
-
Matt Harbison authored
I think this is silly, and I'd rather be explicit. But there's no way to turn off this transform from the command line, and accepting these changes means less noise when running this in the future. See hg 3e84e001b6c1.
-
Matt Harbison authored
This was rewritten by the `set_literals` fixer in `pyupgrade`. See hg f066fc0bdc7a.
-
Matt Harbison authored
This was rewritten by the `dict_literals` fixer in `pyupgrade`. See hg d903647abbd3.
-
- Jan 06, 2025
-
-
Matt Harbison authored
This is the `typing_text` fixer in `pyupgrade`. This type was meant to be for py2/py3 interoperability, being bytes on py2 and str on py3. See hg cb769c0ffe35.
-
Matt Harbison authored
This is the `typing_pep563` fixer in `pyupgrade`. Quoting to delay evaluation hasn't been necessary since adding `from __future__ import annotations` in 1f17abd911a2. See hg 4cb75772818d.
-
Matt Harbison authored
This is the `legacy` fixer in `pyupgrade`, with the `yield` statement yielding loop commented back in. This seems to help pytype in some cases, and hurt it in others. But that can be manually fixed later. See hg e627cc25b6f3.
-
Matt Harbison authored
This is the `legacy` fixer in `pyupgrade`, with the loop yielding the offset of `yield` statements commented out. See hg 5cc8deb96b48.
-
Matt Harbison authored
This probably doesn't matter much, but it reduces the noise when running the tool in the future. See hg 73ab542565e0.
-
Matt Harbison authored
These were different classes in py2, but now a handful of error classes are just an alias of `OSError`, like `IOError`, `EnvironmentError`, `WindowsError`, etc. These were rewritten using a hacked version of `pyupgrade` 3.19.1 that enabled only the `exceptions` fixer. See hg 24ee91ba9aa8 for details.
-
Matt Harbison authored
These were rewritten using a hacked version of `pyupgrade` 3.19.1 that enabled only the `new_style_classes` fixer. See hg 9bd6854aab86 for details. $ hg files -0 'relglob:**.py' | xargs -0 pyupgrade --py38-plus \ --keep-percent-format --keep-mock --keep-runtime-typing
-
- Feb 28, 2025
-
-
Matt Harbison authored
The SourceForge packages were working as recently as late last week, and then I suddenly got a failure that the size of the download changed from what was expected. Let's not trust SourceForge for critical things. See hg 5df7f90d38e7.
-
- Feb 22, 2025
-
-
Matt Harbison authored
I got this when launching WorkBench on Windows (macOS seemed OK): Traceback (most recent call last): File "thg", line 16, in <module> NameError: name '__file__' is not defined It looks like this broke in 326e8dde97a9, as `__file__` was avoided in forzen builds prior to that.
-
Matt Harbison authored
Not sure what this is, but there haven't been any Python 2.6 paths in a long time.
-
- Feb 21, 2025
-
-
Matt Harbison authored
Somehow, upgrading to Python 3.11 to run pytype caused it to complain that: File "/home/mharbison/projects/mercurial/thg/tortoisehg/hgqt/serve.py", line 144, in _tempwebconf: No attribute 'write' on mercurial.config.config [attribute-error] In Union[mercurial.config.config, tortoisehg.util.wconfig._wconfig] Called from (traceback): line 130, in _cmdargs
-
- Dec 25, 2024
-
-
Matt Harbison authored
The goofy definition stub is so that pytype doesn't merge an unknown with the function signature that it sees in the new module, and type it as `Any`. If the real definition changes, it should type the symbol as a union of the two signatures, and hopefully that's good enough to notice the change.
-
- Jan 26, 2025
-
-
muxator authored
Once we recognize that: os.path.dirname(fpath) == os.path.dirname(os.path.realpath(__file__)) We can replace the expression with thg_base_path we introduced before.
-
muxator authored
The invocation of os.path.dirname(os.path.realpath(__file__)) was made in two places. We can centralize it to a single place on top of the file. In the process, the variable can be renamed to thg_base_path. No functional changes.
-
- Jan 16, 2025
-
-
Matt Harbison authored
The version can be overridden by setting `QT_MAJOR` to 5 or 6 in the environment, but it tries to do the right thing by default. I didn't check that all of the same libraries are in the app bundle and need to be removed that are in the Qt5 app, but when skipping that section of post-build customizing, `codesign` reported that it wasn't signed properly. It's just easier to run through it for now and re-sign at the end. Qt5 doesn't support arm64, and requires Rosetta to be installed to run it. Unfortunately, while python, py2app, and PyQt6 are all universal2 binaries, the libraries installed for Qt6 are thin binaries. Maybe there's a way to download the wheels for both architectures and smash them together. Perhaps with something like this: https://github.com/ronaldoussoren/py2app/issues/399#issuecomment-1709305758 For now, we'll just have to build 2 things on two different machines. We might also have the opposite problem we had before with py2app being a universal binary, and defaulting to running the arm64 image on Apple Silicon- it will want to run the amd64 image on an Intel mac, and crash on startup if it was built for AS because the Qt6 libraries are the wrong architecture again. But since I expect the Qt6 stuff to be less stable, let's not worry about removing the amd64 image when building on AS like we do the arm64 image with Qt5 builds.
-
Matt Harbison authored
This will make it easier to switch the version of PyQt to use when building. The old file references in the generated file was manually updated. There is a newer version of Qt5 on macOS, but it was crashing for me on launch when I tried it.
-
- Jan 15, 2025
-
-
Matt Harbison authored
-
Matt Harbison authored
No particular need, it's just that these haven't been updated in awhile.
-
Matt Harbison authored
At the moment, the latest `pyqt6-qt6` package is 6.8.1. By pinning an older version, we can make a build that runs on any Apple Silicon. Mostly this is a convenience for me because I have an older build system.
-
- Jan 16, 2025
-
-
Matt Harbison authored
-