conda-forge / conda-forge/metatensor-feedstock

Naming convention for the different packages on conda

Open
#2 2 comments 1 reaction 0 assignees View on GitHub
question
Dominant language
No language data
Stars
0
Forks
3
PR merge metrics
No merged PRs in 30d

Description

### Comment:

The metatensor project contains a lot of different sub-packages, developed somehow independently. This feedstock currently builds the native library for metatensor-core, but there are also the following packages:

- native library for metatensor-core
- native library for metatensor-torch (C++ TorchScript interface)
- Python bindings to metatensor-core
- Python bindings to metatensor-torch
- metatensor-operations Python package
- metatensor-learn Python package

We are also leaving open the possibility for more language bindings to metatensor-core or metatensor-torch. The question is what's the best way to split the packages on conda-forge. I think the native libraries should be packaged separately from the Python bindings (they are used on their own when running pre-trained model inside simulation engines).

Our current idea would be to have the following packages on conda-forge:

- `metatensor-lib-core` => replaces this repository
- `metatensor-lib-torch` for native metatensor-torch
- `metatensor-python-core` for Python's metatensor-core
- `metatensor-python-torch` for Python's metatensor-torch
- `metatensor-python-operations`
- `metatensor-python-learn`

As well as the following empty packages with only dependencies on the above (as a convenient way for users to install most packages at the same time):

- `metatensor` => would give you `metatensor-lib-core`, `metatensor-python-core`, `metatensor-python-operations` and `metatensor-python-learn` (this would be released with a new, incompatible, version number since we are replacing the package in this repository with a new one)
- `metatensor-torch` => would give you all of `metatensor`, plus `metatensor-lib-torch`, and `metatensor-python-torch`.

----

For reference, the following packages are currently on PyPI:

- `metatensor-core`, containing the native library & Python bindings
- `metatensor-torch`, containing the native metatensor-torch library & Python bindings
- `metatensor-operations`
- `metatensor-learn`

As well as an empty `metatensor` package with dependency on the above. With the proposed package separation above, the following commands would be mostly equivalent:

| conda install | pip install |
|------------------------------|-----------------------|
| metatensor | metatensor |
| metatensor-torch | metatensor[torch] |
| | |
| metatensor-python-core | metatensor-core |
| metatensor-python-torch | metatensor-torch |
| metatensor-python-operations | metatensor-operations |
| metatensor-python-learn | metatensor-learn |
| | |
| metatensor-lib-core | / |
| metatensor-lib-torch | / |

----

@conda-forge/core does this looks like a good packaging plan to you? Is the `-lib` and `-python` somewhat common in the ecosystem or should we adopt a better naming convention?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.