[PATCH] blockmatcher: add missing import introduced two commits ago

[Antonio Muci]

# HG changeset patch
# User Antonio Muci <a....@inwind.it>
# Date 1742771421 -3600
# Mon Mar 24 00:10:21 2025 +0100
# Branch stable
# Node ID daa883d90b1b93790b97e3539c42736e22ad5c85
# Parent 4306fdea53cf8b262f25b938a914cba81d832d11
blockmatcher: add missing import introduced two commits ago

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.

diff --git a/tortoisehg/hgqt/blockmatcher.py b/tortoisehg/hgqt/blockmatcher.py
--- a/tortoisehg/hgqt/blockmatcher.py
+++ b/tortoisehg/hgqt/blockmatcher.py
@@ -29,6 +29,7 @@ from .qtgui import (
QColor,
QFrame,
QHBoxLayout,
+ QMouseEvent,
QPainter,
QPainterPath,
QScrollBar,

[Antonio Muci]

I have to own this mistake: I'd have caught it if I run PyType on the
code base. Sorry again (for the second time in a few days).

I'd like to be able to execute at least the majority of checks locally
(lint, type checks, tests) with a few make commands, before submitting a
patch. Setting a working development venv is easy when using Poetry (or
uv, which I know less), for declaring runtime and development
dependencies. With TortoiseHg it is harder, probably because of
historical reasons and because the application is complex and has to be
supported on a variety of platforms. I am not sure we could easily
migrate to one of those tools.

The final result is that I end up foregoing (and forgetting) basic
development hygiene because of this.

The first version of this email included a long rant about the
TortoiseHg development experience; I deleted that one, because I think
it's better to leave space to allow something come out of this
frustration, hopefully.

Antonio

[Matt Harbison]

On Sunday, March 23, 2025 at 8:33:55 PM UTC-4 Antonio Muci wrote:

I have to own this mistake: I'd have caught it if I run PyType on the
code base. Sorry again (for the second time in a few days).

I'd like to be able to execute at least the majority of checks locally
(lint, type checks, tests) with a few make commands, before submitting a
patch. Setting a working development venv is easy when using Poetry (or
uv, which I know less), for declaring runtime and development
dependencies. With TortoiseHg it is harder, probably because of
historical reasons and because the application is complex and has to be
supported on a variety of platforms. I am not sure we could easily
migrate to one of those tools.

I recently had to setup a new laptop for development, and did it by creating a venv in WSL and using the requirements files in the repo.  There are also a few shell scripts I have locally to run `make` in the hg repo, patch up the venv for pytype like the CI yml file does, and then create a commit message for the pytype runs.  I have no experience with poetry or uv, so I can't help much there.  We definitely need to do something though, and soon, because of the setup.py mess.  Probably we need to do the same thing hg did this cycle.

Alternately if you have an account on heptapod, you can just push topic branches and run CI (with pytype runs).  That might be faster than what you can do locally, depending on your machine.  All you need is to request dev access if you don't already have it.

[Yuya Nishihara]

On Mon, 24 Mar 2025 00:19:47 +0100, 'Antonio Muci' via TortoiseHg
Developers wrote:
> # HG changeset patch
> # User Antonio Muci <a....@inwind.it>
> # Date 1742771421 -3600
> # Mon Mar 24 00:10:21 2025 +0100
> # Branch stable
> # Node ID daa883d90b1b93790b97e3539c42736e22ad5c85
> # Parent 4306fdea53cf8b262f25b938a914cba81d832d11
> blockmatcher: add missing import introduced two commits ago

Queued, thanks.

[Antonio Muci]

Yes, the Heptapod CI helped, because it caught the problem at least.

I'd be happy to streamline the "run everything locally and offline because I am in a transcontinental flight with no wifi" use case (at least on linux/unix); hopefully the CI runs could then become a generalization of that.

I have seen that there was a thread about setup.py in the mercurial mailing list, but I still did not looked at the code. I'll do it.

My story with Python packaging started with Poetry and pyproject.toml; I know it well and maintain some project with it myself. Conversely, I have no clue of the "imperative age" of python packaging.

My sensation is that with TortoiseHg everything will be more difficult than the standard pure-python application, at least because of Qt{5,6}, PyQt, Scintilla, PyType with its strange requirement of a specific python version, and the complex incarnation needed for running PyTest.

We'll get there, eventually, won't we? :)

Antonio

--
You received this message because you are subscribed to the Google Groups "TortoiseHg Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thg-dev+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/thg-dev/23b7ba7f-2a60-4692-bb1c-6062dd75cb39n%40googlegroups.com.