Standardize environment.yml
#81
Conversation
| ```yaml | ||
| name: test | ||
| dependencies: | ||
| - numpy >=1.10 |
There was a problem hiding this comment.
What about conditions if a dependency is used on different platforms, python versions, implementations, etc.?
There was a problem hiding this comment.
In this CEP I only want to document the current state, mostly as available in the original implementation in conda.
There are a number of extensions in community projects that are out of scope (e.g. I think micromamba has a sel(xxxx): numpy syntax for selectors).
|
|
||
| Required, `list[str | dict[str, Any]]`. | ||
|
|
||
| The simplest form for this section is a list of `str` encoding `MatchSpec`-compatible requirements. These items MUST be processed as conda requirements and submitted to the solver (along with `channels`) to obtain the contents for the resulting conda environment. |
There was a problem hiding this comment.
Should platform selectors be mentioned here or is that implied with MatchSpec-compatible?
There was a problem hiding this comment.
AFAIK, environment.yml doesn't support platform selectors like meta.yaml, doesn't it?
There was a problem hiding this comment.
You're right, my bad. Would be a nice feature though.
Co-authored-by: Marco Esters <[email protected]>
Adds a type for representing a `environment.yaml` based on conda/ceps#81
| - `channels`: conda channels that will be used to resolve the dependencies. | ||
| - `variables`: Environment variables that SHOULD be added to the `conda-meta/state` file in the resulting environment. | ||
|
|
||
| Additional sections can be present, but they MUST be ignored and the user SHOULD receive an informative warning about them. |
There was a problem hiding this comment.
conda-lock cannot abide by this CEP because it includes a platforms key and one other. Any ideas on how to make that work?
Standardizing the popular
environment.ymlinput files.📝👓 Markdown preview