Thu, 11 Jan 2024 17:52:13 +0100 branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Thu, 11 Jan 2024 17:52:13 +0100] rev 51325
branching: merge stable into default
Mon, 08 Jan 2024 13:35:02 +0100 contrib: add a set of scripts to run pytype in Docker
Anton Shestakov <av6@dwimlabs.net> [Mon, 08 Jan 2024 13:35:02 +0100] rev 51324
contrib: add a set of scripts to run pytype in Docker Having a simple way to run pytype for developers can massively shorten development cycle. Using the same Docker image and scripts that we use on our CI guarantees that the result achieved locally will be very similar to (if not the same as) the output of our CI runners. Things to note: the Dockerfile needs to do a little dance around user permissions inside /home/ci-runner/ because: - on one hand, creating new files on the host (e.g. .pyi files inside .pytype/) should use host user's uid and gid - on the other hand, when we run the image as uid:gid of host user, it needs to be able to read/execute files inside the image that are owned by ci-runner Since local user's uid might be different from ci-runner's uid, we execute this very broad chmod command inside /home/ci-runner/, but then run the image as the host user's uid:gid. There might be a better way to do this.
Mon, 18 Dec 2023 15:52:17 -0300 pytype: use "$(hg root)" instead of `hg root` to make shellcheck happier
Anton Shestakov <av6@dwimlabs.net> [Mon, 18 Dec 2023 15:52:17 -0300] rev 51323
pytype: use "$(hg root)" instead of `hg root` to make shellcheck happier
Mon, 18 Dec 2023 15:40:48 -0300 pytype: update check-pytype.sh to select target automatically
Anton Shestakov <av6@dwimlabs.net> [Mon, 18 Dec 2023 15:40:48 -0300] rev 51322
pytype: update check-pytype.sh to select target automatically We have python3.11 on CI, so we can run pytype targeting that version. On the other hand, we don't have python3.7 on CI anymore, so we can't run pytype for 3.7 anymore (interpreter not found). I think it's fine to make pytype select the appropriate target depending on the version of the interpreter it's running under.
Tue, 19 Dec 2023 22:54:52 +0100 git-hgext: adjust to the lack of `changelog.heads` method
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 19 Dec 2023 22:54:52 +0100] rev 51321
git-hgext: adjust to the lack of `changelog.heads` method We don't have a `heads` method returning nodeid, but this is very easy to get the same result. This was flagged by pytype. We can note that the fact this code did not break is probably a good sign that it is dead code. However this is a question outside of the scop of this series.
Tue, 19 Dec 2023 22:21:31 +0100 remotefilelog: drop dead code
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 19 Dec 2023 22:21:31 +0100] rev 51320
remotefilelog: drop dead code As pytype flagged bug in this method it highlighted that this methode being never called anywhere.
Tue, 19 Dec 2023 22:07:59 +0100 pytype: use the right signature for the `__delitem__`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 19 Dec 2023 22:07:59 +0100] rev 51319
pytype: use the right signature for the `__delitem__` It is not because it is NotImplemented that it should use a bad signature. Fix it to please pytype.
Tue, 19 Dec 2023 22:07:21 +0100 pytype: use the right signature for the `__setitem__`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 19 Dec 2023 22:07:21 +0100] rev 51318
pytype: use the right signature for the `__setitem__` It is not because it is NotImplemented that it should use a bad signature. Fix it to please pytype.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 tip