Add some metadata when packaging in the metadata.txt

[Gustry]

I would like to add some metadata when packaging the plugin such as datetime, commit ID and commit number :

commitNumber=812
commitSha1=9259b6d23f31fb1116e9469b2b58c8cf71d7137c
dateTime=2022-03-15T13:11:46Z

These are not official in QGIS, but I can make a PR in the documentation to include them in the file https://github.com/qgis/QGIS-Documentation/blob/master/docs/pyqgis_developer_cookbook/plugins/plugins.rst#plugin-metadata

[Guts]

Why not?

But maybe we should use a different section than the [general]? I suggest: [development]

These are not official in QGIS, but I can make a PR in the documentation to include them in the file https://github.com/qgis/QGIS-Documentation/blob/master/docs/pyqgis_developer_cookbook/plugins/plugins.rst#plugin-metadata

I don't know how works the documentation update but it sounds strange to update it roughly for an external need (3rd party library I mean and mainly for your projects purposes) without proposing an official evolution, no?

[Gustry]

But maybe we should use a different section than the [general]? I suggest: [development]

I don't have a strong opinion. Maybe package is better if change the default section ?

I just tried to work in this change.

But to have another section and to use it nicely, I need to use configparser. I need to read it the metadata.txt using this lib, add new section and write it again in the file with the library. I noticed just now that the changelog line is somehow not the same anymore, maybe because it's multiline ? And the file is totally rewritten etc. So before I check deeper, do we really want a new section ? :)
It's somehow linked to the version key already there in the general section.

I don't know how works the documentation update but it sounds strange to update it roughly for an external need (3rd party library I mean and mainly for your projects purposes) without proposing an official evolution, no?

I totally understand your question.
I could skip this sentence in my PR and qgis-plugin-ci would just add these silently in ZIP. But my idea is that if another tool doing zip for QGIS or if someone who wants to add these information in their ZIP, I would like them to use the same keys.
It's what I did before working on this PR. I was checking in the documentation if these keys weren't already there.

Generating ZIP from commits (without any tag, so not a proper version in the metadata.txt) is an issue for me. The QGIS plugin manager might lost track of this plugin if the developer is not careful.

[3nids]

Another approach would be to fill the fields if they are found in the metadata. Would that be enough?

[Gustry]

Yes indeed, like we do for changelog and version.

[Gustry]

Done. It will be in the metadata.txt only if the keys are there before.

[Guts]

But to have another section and to use it nicely, I need to use configparser. I need to read it the metadata.txt using this lib, add new section and write it again in the file with the library. I noticed just now that the changelog line is somehow not the same anymore, maybe because it's multiline ? And the file is totally rewritten etc. So before I check deeper, do we really want a new section ? :)

I've been thinking and my answer is definitely yes (sorry). I'm really convinced this is a bad idea to freely modify the metadata.txt general section from a third-party tool like qgis-plugin-ci. PEPs about how extrnal tools have to store their specific settings in setup.cfg or pyproject.toml are good readings and bases to argue in favor of a dedicated section.

As discussed with @3nids about the other topic of translations management, I think we should make qgis-plugin-ci as agnostic as possible.

[Gustry]

I've been thinking and my answer is definitely yes (sorry).

Yes, you are free to do it in the section you want. The PR is only replacing existing line, whatever the section.

I will rebase for the release.

[Guts]

Yes, you are free to do it in the section you want. The PR is only replacing existing line, whatever the section.

Okay, this seems to be a "compromis". I'm still afraid that the project becomes too hard to maintain or to understand of what it does exactly with plugins files...

I suggest a proper section in documentation at least.

[Gustry]

Ok, I have added the notes @Guts

[Guts]

Ok, I have added the notes @Guts

Thanks you for taking my concerns in account 🙏!