Allow extra section in manifest

[awvwgk]

This PR adds an extra section to the package manifest. It is excluded from checks in Fortran fpm.

The general idea behind this section is:

• allow third party tools to store information in the package manifest
• stage new entries for the fpm registry without requiring a change in the manifest reference

[milancurcic]

allow third party tools to store information in the package manifest

I don't understand this. Can you give a concrete example? Why would other tools want to store info in the manifest? Would these be fpm plugins or something else?

[awvwgk]

I have nothing particular in mind yet, but one idea would be to allow tools like FORD/fprettify/... to read from fpm.toml instead of their own input file:

[extra.ford]
output_dir = "./docs"
docmark = "<"
predocmark = ">"
[extra.fprettify]
indent = 4

Managing those entries would be the responsibility of the respective tools and fpm just allows for a free space to do so.

The advantage of using fpm.toml is that the meta data has to specified only once, it reduces the repetition of project name, layout, descriptions, ... in case it is adapted by a commonly used tool.

[milancurcic]

Got it. I'm not opposed to it, but also don't see the need until users ask for it.

If others like it, I don't mind it going forward. @everythingfunctional @LKedward @urbanjost @certik what do you think?

[everythingfunctional]

Once you put it in, you have to support it. Without a specific use case or request for it, I'd be hesitant to put it in. It's an interesting idea, and would encourage tools and users to converge around supporting and using fpm, so I'm not opposed to it. I just don't think it should be done yet. We've got plenty of other things to get done first.

[LKedward]

I am not opposed to this, I can see it's uses, particularly this:

The advantage of using fpm.toml is that the meta data has to specified only once, it reduces the repetition of project name, layout, descriptions, ... in case it is adapted by a commonly used tool.

which opens the way for others to develop more tooling for the Fortran ecosystem.

Once you put it in, you have to support it.

Regarding support, I think the point here is that the section is explicitly ignored by fpm, so there is no burden of maintenance for us.

[everythingfunctional]

Regarding support, I think the point here is that the section is explicitly ignored by fpm, so there is no burden of maintenance for us.

True, there is essentially no maintenance cost for us, other than explicitly ignoring it and not being able to use that table for anything in the future. So it could be worth it, but as I said, I think we've got other things to worry about first.

[awvwgk]

This has been stale for while, therefore closing it now, we can revisit this feature later in case there is need.