Add aiida-core.atomic_tools sub-package

[chrisjsewell]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• It looks like the 'aiida-core.atomic_tools' output doesn't have any tests.
• Recipes should usually depend on matplotlib-base as opposed to matplotlib so that runtime environments do not require large packages like qt.

[chrisjsewell]

@conda-forge-admin, please rerender

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• Recipes should usually depend on matplotlib-base as opposed to matplotlib so that runtime environments do not require large packages like qt.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[chrisjsewell]

@astamminger what do you think of this?
It is really desirable to have this, to create conda packages for plugins that have an install_requires against aiida-core[atomic_tools] (like aiida-fleur, aiida-nwchem, etc).

Currently, you would need to use this like: conda install aiida-core aiida-core.atomic_tools, as opposed to just conda install aiida-core.atomic_tools
I think maybe (but not definite) that this is better than adding aiida-core to the dependencies of aiida-core.atomic_tools, since it is more modular 🤷

Also, it would be nice to run a test, to check the dependencies and version directly aligns with https://github.com/aiidateam/aiida-core/blob/7772adcae4113404eef27e1e964d7d55734c924c/pyproject.toml#L86
But not sure if this is possible, since you cannot, for instance, really use pip check for this: pypa/pip#4086

[astamminger]

Hi @chrisjsewell not easy to answer :D

IMHO I would also opt for the modular approach you suggested (I think we need to update the run_constrained section in aiida-core to ensure that only the correct version can be installed. I guess we should use your nifty pin_subpackage there as well, shouldn't we?) On the other hand, having aiida-core in the deps would more closely mimic the pip install aiida-core[atomic-tools] behavior. So i guess both ways have their pros and cons and in the end it boils down to personal preference.

Regarding your last point: I think such a test would be a nice feature but at the moment I honestly do not know if and how that could be achieved.

[chrisjsewell]

On the other hand, having aiida-core in the deps would more closely mimic the pip install aiida-core[atomic-tools] behavior.

Yeh I'm going to go this way actually, as it's simpler: no "bi-directional" run_constrained needed, and downstream plugins only need to install aiida-core.atomic_tools

[chrisjsewell]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/aiida-core-feedstock/actions/runs/2651680424.