Read metadata from pyproject.toml where possible

[p-j-smith]

The metadata.yml file required for a kit contains several fields that are available in the project's pyproject.toml file. It would be great if the data were read from the pyproject.toml.

Based on the specification of project metadata in pyproject.toml files, I think the following could be removed from metadata.yml and read from pyproject.toml:

• project_name
• authors
• maintainers
• description
• keywords
• license
• project_home
• documentation_home
• python_requires
• mdanalysis_requires (read from the list of dependencies)
• development_status
• community_home
• changelog

This way, if I update any of these fields for my project I don't need to remember to update them here too.

I imagine the template metadata.yml file would then look something like this:

# TEMPLATE MDAKit file
# --------------------
# 
# Please replace ALL entries with appropriate content for YOUR MDAKit.
# Below we use the placeholder GH_HOST_ACCOUNT for the GitHub account where
# the source code repository is held, typically your username or the 
# organization that you're part off.
# MYPROJECT is the name of your project (the repository name and here
# we assume that this is also the PyPi/conda package name) whereas 
# MYPACKAGE is how you import it in python.
#
# See https://mdakits.mdanalysis.org/add.html for more information. 
#
# Required entries
## str: link to pyproject.toml file
pyproject: https://github.com/MYNAME/MYPROJECT/blob/main/pyproject.toml
## str: the type of documentation available [UserGuide, API, README]
documentation_type: UserGuide + API

# Optional entries
## List(str): a list of commands to use when installing the latest
## release of the code. Note: only one installation method can currently
## be defined. We suggest using mamba where possible (e.g.
##   mamba -c conda-forge install MYPROJECT
## for a conda package installation)
install:
  - pip install MYPROJECT
## List(str): a list of commands to use when installing the mdakit from its
## source code.
src_install:
  - pip install git+https://github.com/GH_HOST_ACCOUNT/MYPROJECT@main
## str: the package name used to import the mdakit
import_name: MYPACKAGE
## List(str): a list of commands to use when attempting to run the MDAKit's tests
## If you package your tests inside your package then you can typically use the 
##     pytest --pyargs MYPACKAGE.tests
## command as shown below. 
## Otherwise you need to include commands to make the tests available. 
## For example, if the tests are in the repository at the top level under `./tests`:
## First use `git clone latest` to either clone the top commit for "develop" runs or check out
## the latest tag for "latest release" checks. Then then run pytest:
##    - git clone latest
##    - pytest -v ./tests
## Feel free to ask for advice on your pull request!
run_tests:
  - pytest --pyargs MYPACKAGE.tests
## List(str): a list of commands to use to install the necessary dependencies required
## to run the MDAKit's tests.
## The default below _might_ be sufficient or you might not even need MDAnalysisTests:
## make sure that it is appropriate for how you run tests.
test_dependencies:
  - mamba install pytest MDAnalysisTests
## str: the organisation name the MDAKit falls under
project_org: GH_HOST_ACCOUNT 
## List(str) a list of publications to cite when using the MDAKit
## Links to scientific publications or stable URLs (typically of the form
## https://doi.org/<DOI> or to a preprint server)
publications:
  - URL1
  - URL2

[IAlibay]

I've thought about this, but because there's inconsistencies in pyproject.toml files (and its adoption), I've stayed away from doing this for now.

It's something I'll probably revisit later.

[IAlibay]

Probably to further explain the current status of things - at some point after the UGM I'll probably be looking to do a big refactor / documentation drive for the CI backend, that way we can start working on streamlining things a bit.

[p-j-smith]

I've thought about this, but because there's inconsistencies in pyproject.toml files (and its adoption), I've stayed away from doing this for now.

That's fair - I can see how it could be tricky

I'll probably be looking to do a big refactor / documentation drive for the CI backend, that way we can start working on streamlining things a bit.

Okay, sounds great. Feel free to close if it doesn't fit with your plans for streamlining things