Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clearer and more detailed specification of author and maintainer metadata #995

Open
apirogov opened this issue Feb 14, 2024 · 0 comments
Open
Labels
specification Issue regarding fpm manifest and model

Comments

@apirogov
Copy link

apirogov commented Feb 14, 2024

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@address.com>.

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

Additional Information

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
specification Issue regarding fpm manifest and model
Projects
None yet
Development

No branches or pull requests

1 participant