You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Motivation
The current specification does not really say how
author
andmaintainer
must be like and provides an Example, most packages tend to use a free-form name forauthor
and give an e-mail formaintainer
- 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
andgit
of the formFree 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
andmaintainer-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
Additional Information
No response
The text was updated successfully, but these errors were encountered: