conda-forge / conda-forge/metatensor-feedstock
Naming convention for the different packages on conda
- 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
Assessment
This issue has not been assessed yet.