Using namespace pakages as plugins/extensions

[NeoCortex97]

Hi everyone,
Just as a disclaimer upfront:
I am new to poetry and I am working on my very first project with it. I work in multiple languages and therefor need different set of tools and tool-chains. As you might imagine, I absolutely hate repetitive tasks, like writing the exact same files for setting up a build system, or creating the exact same directory structure, or even performing the same commands every time to setup a git repo, ....
So over time I acquired a nice collection of scripts making my life better and performing the tedious bits of the trade as a developer.
My boss at my university job saw me setup a project for a new assignment he gave me with just one script and now he wants to have all my little and big helpers...

The bad part is that most of them are written badly in about 10 different languages and most of them are pretty much exclusive to my specific setup. So I sat down and explained why I couldn't give him my tools folder and he understood. But now my assignment is to make my tools into a semi consistent suite that is mostly platform agnostic (We run 95% Ubuntu, about 5% other linux and we have some folk working in wsl2 and about two mac folks.) At least the linux and mac guys should be able to use them and he wants them as flexible as possible, so he does not need to waste ssd space on his mac for java tooling and stuff he will not use.

I included the genesis of my task, so you get a rough idea what I am trying to accomplish. I decided I want to use poetry, because I saw it used in the typer docs - I am using typer as a cli library - and loved it on my first little toy project. To make my task simpler, i figured that I will bundle things into several extensions that sit in a common native namespace package, but now my ability to search the poetry docs is starting to fade and I need some help structuring my project.

1. Should I put all my packages in one giant repo and make poetry build multiple wheels with only some parts?
2. If that's so, where can I get an example on how to do that?
3. Should I rather put every collection of extensions into its own repo and tell poetry that the internal module name is different from the name of the wheel that is built?
4. If you agree to 3: Is there somewhere I could get documentation on how to do so?
5. Do you know of a better way to implement plugins/extensions?
6. If so: Can you link me to that?
7. Do you have any advice how I could avoid circular dependencies?
8. Do you have any advice how I could keep my depenencies clean? (Explanation below)

Explanation:
I want to be as modular as possible. I'll use macros as an example for now.
I intend to call my macro extension commander - pls don't ask why. And I want to also package sets of macros. I intend to allow duplicates of macro names and want to run all macros that are registered to the same trigger name. For simplicity sake I would use "build" as an example.
Maybe I have multiple package that define a build macro. Maybe one for poetry projects, one for cmake project, one for gradle projects and one for npm projects. Let's assume that the macros can figure out if they are applicable and do so.
I feel like im getting on too much of a tangent r n. Let's get back to the point. I would like the packages that only deliver sets of macros to tell my core tool that they need commander to work, but don't want to include commander as a dependency in them, so i can uninstall one of these without possibly killing others and to avoid version problems that may arise.

But maybe I'm too much of a noob and all this is an non-issue.
And please be kind with my spelling, I'm a little sick and English is not my native language.
Thanks for taking the time to read through this mess and trying to make sense of it.