Thanks a lot! These are very valuable insights.

These addons are mostly in their own subfolders, but not always (we might or might not want to change this - the jury is not yet out on this). There are also ideas floating in the room to extract at least some of the addons to completely independent repositories. I have the feeling that subprojects would serve as a temporary middle way where the addons are still in the same repo but a bit more independent from the main code. Does this change your gutt feeling about using subprojects for this purpose or do you still prefer the boolean-variable approach?

This will then also solve the problem that for publishing the addon as a separate package, you need a separate pyproject.toml file

Just to make sure that I parse this sentence correctly: one still needs to have a separate pyproject.toml + main meson.build file for each addon - just that the latter is really simple and sets only the project metadata and then includes the meson build file of the addon, right?

Does this change your gutt feeling about using subprojects for this purpose or do you still prefer the boolean-variable approach?

Not sure without trying. Both methods are easy to evolve into moving the add-on to a separate repo. And for the add-ons that aren't completely isolated, I think subprojects aren't an option. One advantage of subprojects is that it's slightly cleaner to have a separateproject() call (see code outline below). I'd probably still try the boolean flag option first, but the differences may be minor/subtle.

one still needs to have a separate pyproject.toml + main meson.build file for each addon - just that the latter is really simple and sets only the project metadata and then includes the meson build file of the addon, right?

I think yes, but now I am unsure of parsing that sentence, so let me sketch it out. The repo will look like:

# top-level of the repomeson.build       # contains a project() call for the main projectmeson.options   # defines the `addon1_standalone` option (default: false)pyproject.toml   # contains all metadata for the main project    src/        meson.build     # contains `if use_addon1; subdir(addon1)`         addon1/            meson.build      # contains `dependency(my-dep-for-addon1)`            meson.options   # also defines the `addon1_standalone` option (default: true)            pyproject.toml  # contains all metadata for addon1

Thesrc/addon1/meson.build should have a separateproject() call to ensure that thatmeson.build file can be used standalone:

ifget_option('addon1_standalone')# build option, defined in meson.optionsproject('addon1','c','cython'  )# add meson_version, default_options, etc. as neededendif

Thesrc/addon1/pyproject.toml file should contain that same flag[build-system] and[project] tables with metadata foraddon1.

Then to build your wheels:

# from top-level directorypython -m build --wheel  # build wheel for main projectcd src/addon1python -m build --wheel  # build wheel for addon1

Ah, this is an interesting idea. But sadly it doesn't seem to work. With theif get_option(...) aroundproject, Meson complains thatproject is not the first statement in the meson file if I compile the addon separately. But without it the compilation of the main project fails because of a "Second call to project()". Any idea how to workaround this limitation? Eg, is it possible to have a main meson build file that is not calledmeson.build?

I did a bit more research and it seems people recommend subprojects in this case (e.g.mesonbuild/meson#6404 andmesonbuild/meson#9929). An alternative approach would be to have an<root>/addons folder that only contains the pyproject.toml + main meson build file for each addon, and a symlink to the main addon source code.

Ahh that's too bad. The table inmeson#6406-comment summarizes it well:

There will be some limitations though I expect, for the "have one monolithic project for local development" use case. For one, the add-on has to be a namespace package for it to show up in-tree in the monolithic mode (but that's okay still). More importantly, I suspect editable installs for the monolithic mode won't work for the add-ons in subprojects.