fpm icon indicating copy to clipboard operation
fpm copied to clipboard

Clearer and more detailed specification of author and maintainer metadata

Open apirogov opened this issue 1 year ago • 0 comments

Motivation

The current specification does not really say how author and maintainer must be like and provides an Example, most packages tend to use a free-form name for author and give an e-mail for maintainer - I believe it comes from just doing what the example shows.

I don't know if this is actually the intent or just unclarity in the current spec, but I believe this is problematic how it is right now. For once thing, it is a weird practice to write for the author just a name without contact possibility, but for the maintainer (who could be a different person altogether) just state an e-mail address.

Furthermore, specifically automated parsing of package metadata is made hard if no clearer definition provided and enforced.

FORTRAN is used a lot in scientific codes, where attribution of contributors is key, for that reason I believe that this is an important issue to be addressed. Currently there are various standards emerging for technical artifacts such as code and tooling should support/make it simpler to implement things such as CITATION.cff or codemeta.json in their repository.

We are developing a language-independent tool that is supposed to help with that, and considered supporting FORTRAN by reading/writing fpm metadata, and were a bit surprised to see how the FPM spec is quite sub-par, even though the other package managers (linked below) already had some better spec in this regard.

Specification

The simplest "solution" would to enforce a format such as used by poetry and git of the form Free Text Name <[email protected]>.

To not break existing packages, the email part could be optional, and tools can assume that if the <...> part is missing and the string is not having an @ symbol, it is a name.

A better solution would actually be having more structured metadata, the minimally-invasive way implemented by e.g. introducing fields author-email and maintainer-email (which, again, avoids breaking existing packages)

Furthermore, in any case, it would be better if both of these would be a list - there can be many collaborating authors that were crucial for a project, and also possibly multiple current maintainers.

Prior Art

  • https://python-poetry.org/docs/basic-usage/
  • https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html
  • https://docs.npmjs.com/cli/v10/configuring-npm/package-json#people-fields-author-contributors
  • https://citation-file-format.github.io/
  • https://codemeta.github.io/

Additional Information

No response

apirogov avatar Feb 14 '24 13:02 apirogov