add(configuration): ability to store configuration in [tool:qgis-plugin-ci] section in plugin's metadata.txt

[Guts]

Description

We already reading/writing the plugin's metadata.txt so why not loading full config from there? Well, talking with colleagues, from a plugin dev perspective, it looks like a good idea to store everything in the same config file.

@Xpirix @timlinux is there a risk to see this extra section spotted by checks running at publish time?

plugin_path is still mandatory but maybe we could add a small lookup logic tyo find it (as parent folder of the metadata.txt) in a next PR?

I used claude.ai to write unit tests.

Funded by Oslandia.

Author's checklist

• I have read the contributing guidelines and my pull request follows them.
• my commits tend to comply with Conventional Commits; so they are descriptive and explain the rationale for changes. Messages and description are self-explanatory to make the git log a readable story of the project.
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary documentation (if appropriate).
• commits which fix bugs include Fixes #11111 at the bottom of the commit message.

Tip

If you forgot to do this, don't be shy and write the same statement into this text field with the pull request description.

AI tool usage

• AI tool(s) (Copilot, Claude, or something similar) supported my development of this PR. See our policy about AI tool use. Use of AI tools must be indicated. Failure to be honest might result in banning.

Reviewer's checklist

• I remember to check the "Author's checklist" above and ask the author to update the PR description if any of the items are not checked.
• I remember that welcoming new contributors is more important than nitpicking on code style. I will be kind and respectful in my review comments.

[github-actions]

Package	Line Rate	Branch Rate	Health
.	72%	66%	➖
repository	100%	100%	✔
translation_clients	90%	61%	✔
Summary	74% (694 / 939)	65% (171 / 262)	➖

Minimum allowed line rate is 60%

[3nids]

Tihs makes sense to me.
Some thoughts though:

• adding a 4th config option for me should wait for v3. There we decide for a single source of truth to reduce code quantity and chances of different behaviors? -- maybe 2, but not 4 ;)
• I guess this will mean adding a new param to the CLI to give it the location of the metadata file (this will be one parameter less for the plugin path). Other options are non valid for me (moving/copying or configuring) since that would mean a required building step to test the plugin while you develop.

I'm just seeing the need for a cleanup before putting more, but I'm ok to make it land in v2 if you want to, no strong opinion.

[Xpirix]

is there a risk to see this extra section spotted by checks running at publish time?

I don't think so. I guess the checks are mainly checking on missing mandatory fields rather than extra ones and wouldn't probably take them into consideration (not saved in the DB, will stay in the metadata) if not declared in the validators.

[Guts]

adding a 4th config option for me should wait for v3. There we decide for a single source of truth to reduce code quantity and chances of different behaviors? -- maybe 2, but not 4 ;)

@3nids I agree that this results in a lot of different configuration files.

Come to think of it, this is due to the fact that, on the one hand, a tool often tends to provide its own configuration file, and on the other hand, the Python ecosystem is still torn between setup.cfg and pyproject.toml... and the QGIS ecosystem has chosen to do something specific!

It is hard to choose, but if we had to keep only 3, I would suggest:

• pyproject.toml
• metadata.txt
• setup.cfg

And if we had to keep only 2:

• pyproject.toml
• metadata.txt

Maybe we can add this new option in V2 and remove another one in V3?

Thoughts @Gustry?

I guess this will mean adding a new param to the CLI to give it the location of the metadata file (this will be one parameter less for the plugin path).

Sure.

Other options are non valid for me (moving/copying or configuring) since that would mean a required building step to test the plugin while you develop.

Not sure to understand here.