Use a dataclass for "branches" by encukou · Pull Request #703 · python/buildmaster-config

encukou · 2026-04-16T09:51:08Z

We treat the main branch specially, and we use a pseudo-branch for the Pull Request buildbots.

We currently to pass branch around as a string, and it's not clear what for the string is in ('main' vs. '3.15'; 'PR' vs. '3').
This PR moves to a dataclass, and gives names for the properties and conditions. For example:

not branch.is_pr instead of if branch not in ("3",)
branch.wasm_tier == 2 instead of branchname in {"3.11", "3.12"}
use branch.version_tuple instead of an if ladder starting with if branch == MAIN_BRANCH_NAME: branch = MAIN_BRANCH_VERSION

For maintainer convenience, running branches.py in a terminal will dump all the branch info:

name:                    'main'  '3.14'  '3.13'  '3.12'  '3.11'  '3.10'    'PR'           
version_tuple:           (3, 15) (3, 14) (3, 13) (3, 12) (3, 11) (3, 10)   None           
git_ref:                 'main'  '3.14'  '3.13'  '3.12'  '3.11'  '3.10'    None           
builddir_name:           'main'  '3.14'  '3.13'  '3.12'  '3.11'  '3.10'    'pull_request' 
builder_tag:             'main'  '3.14'  '3.13'  '3.12'  '3.11'  '3.10'    'PullRequest'  
sort_key:                -9999   -14     -13     -12     -11     -10       0              
is_main:                 True    False   False   False   False   False     False          
is_pr:                   False   False   False   False   False   False     True           
gil_only:                False   False   False   True    True    True      False          
monolithic_test_asyncio: False   False   False   False   False   True      False          
wasm_tier:               2       2       2       3       3       None      2

This change makes regular builder setup very similar to PR builder setup. This PR stops short of merging them, let's do that later in a separate commit.

Also: add buildersuffix and tags to BaseBuild, instead of accessing them through getattr.

encukou · 2026-04-16T09:53:08Z

+        if branch.name == "3.13":
            self.py313_setup(branch, *args, **kwargs)


Branching on name smells, but I kept it here to match the py313_setup name.

vstinner

This change makes the value more readable and easier to maintain, thanks! Here are some suggestions.

vstinner · 2026-04-16T10:09:35Z

+class BranchInfo:
+    name: str
+    version_tuple: tuple[int, int] | None
+    git_ref: str | None


I'm a little bit confused by "git_ref" name. You may rename it to "git_branch".

OK, I guess Git terminology isn't commonly known.
Reusing “branch” for something else is confusing too, though.

vstinner · 2026-04-16T10:11:02Z

+
+    # Branch features.
+    # Defaults are for main (and PR), overrides are in _maintenance_branch.
+    gil_only: bool = False


Nowadays, Free Threading term is more common. You may replace gil_only with its opposite value: "free_threading = True".

But, the opposite would be both_free_threading_and_gil = True :)
Let's use free_threading_only = True when the GIL builds are dropped.

Instead of if 'nogil' in tags and branch.gil_only: continue, I would expect something like if 'nogil' in tags and not branch.support_free_threading: continue. But it's not a big deal, I'm fine with gil_only if you prefer to keep it.

I'm fine with gil_only here for now, especially since we're still using the nogil tag for FT. We should probably migrate both towards 'free-threading' verbiage at some point, but I'm not in a rush for it.

vstinner

LGTM

vstinner · 2026-04-16T13:43:11Z

+
+    # Branch features.
+    # Defaults are for main (and PR), overrides are in _maintenance_branch.
+    gil_only: bool = False


Instead of if 'nogil' in tags and branch.gil_only: continue, I would expect something like if 'nogil' in tags and not branch.support_free_threading: continue. But it's not a big deal, I'm fine with gil_only if you prefer to keep it.

zware

LGTM!

zware · 2026-04-16T16:07:26Z

            name=buildername,
            workernames=[worker.name],
-            builddir="%s.%s%s" % (branchname, worker.name, getattr(f, "buildersuffix", "")),
+            builddir=f"{branch.builddir_name}.{worker.name}{f.buildersuffix}",


Sidenote: I'd really like to get us switched to using the builder name rather than the worker name for build directories, but it's probably going to require coordination with owners since there may be a bunch of (very large, due to the size of the checkout) dead directories left sitting around after such a switch.

It occurs to me that you may be introducing a nice way to do that progressively with this PR; we can set name_builddir_after_builder = True on new branches and use that to choose the builddir name here.

This is all just musing for the future, though, not actually related to this PR :)

zware · 2026-04-16T16:20:57Z

+
+    # Branch features.
+    # Defaults are for main (and PR), overrides are in _maintenance_branch.
+    gil_only: bool = False


I'm fine with gil_only here for now, especially since we're still using the nogil tag for FT. We should probably migrate both towards 'free-threading' verbiage at some point, but I'm not in a rush for it.

Use a dataclass for "branches"

c4477f1

encukou requested a review from zware April 16, 2026 09:51

encukou commented Apr 16, 2026

View reviewed changes

vstinner reviewed Apr 16, 2026

View reviewed changes

Rename git_ref to git_branch

ee48c41

vstinner approved these changes Apr 16, 2026

View reviewed changes

zware approved these changes Apr 16, 2026

View reviewed changes

		if branch.name == "3.13":
		self.py313_setup(branch, args, *kwargs)

Uh oh!

Conversation

encukou commented Apr 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vstinner left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vstinner left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zware left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants