-
-
Notifications
You must be signed in to change notification settings - Fork 299
multi-output: document full/lite splits with optional dependencies #2168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1655,6 +1655,37 @@ add some information on r packages which make heavy use of `noarch: generic` | |
- [importlib_metadata and importlib-metadata](https://github.com/conda-forge/importlib_metadata-feedstock/blob/main/recipe/meta.yaml) | ||
- [typing_extensions and typing-extensions](https://github.com/conda-forge/typing_extensions-feedstock/blob/main/recipe/meta.yaml) | ||
|
||
### Common patterns | ||
|
||
#### Splitting out heavy optional dependencies | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The previous (low-effort) approach for this was to add the example in the list above (under "Distributing the same project with different sets of dependencies"), and then the pitfall in the section below. This section has a bit both, hence the confusion. I'd rather:
That said, the information you have written here is accurate and I don't want to bikeshed too much. Feel free to ignore my feedback or only take into account parts of it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmh, fair point, doing it this way is a bit of mess. I found the list structure a bit annoying because it somewhat strongly enforces brevity and discourages explanations beyond a short summary, but it is just a more detailed explanation of a special case of |
||
|
||
When a package has especially large optional dependencies it can be useful to split the package into a "lite" version that depends only on the core dependencies and a "full" version that depends on the "lite" version and all optional dependencies. The `pin_subpackage` function helps to ensure that the "full" version will pull the exact version of the "lite" version. As an example consider the [seaborn recipe](https://github.com/conda-forge/seaborn-feedstock/blob/eec88f0116a26c2e205daab10193e38e96407cab/recipe/meta.yaml) with optional statsmodels dependency: | ||
|
||
```yaml | ||
- name: seaborn | ||
build: | ||
noarch: python | ||
requirements: | ||
run: | ||
- statsmodels >=0.12 | ||
- {{ pin_subpackage('seaborn-base', exact=True) }} | ||
``` | ||
|
||
In order to prevent the "lite" version `seaborn-base` to pull in seaborn versions before the package split, `run_constrained` will ensure that the `seaborn-base` package can only be installed together with the matching version of the `seaborn` package. | ||
|
||
```yaml | ||
- name: seaborn-base | ||
build: | ||
noarch: python | ||
requirements: | ||
run_constrained: | ||
- seaborn ={{ version }}=*_{{ build }} | ||
``` | ||
|
||
:::important | ||
Counter-intuitively `{{ pin_subpackage('seaborn-base', exact=True) }}` will only work in the requirements section but not in `run_constrained` (see [conda-build#4415](https://github.com/conda/conda-build/issues/4415)). Use `seaborn ={{ version }}=*_{{ build }}` to ensure that the `seaborn-base` package can only be installed with the matching version of the `seaborn` package. | ||
::: | ||
|
||
### Common pitfalls with `outputs` | ||
|
||
This is a non-exhaustive list of common pitfalls when using `outputs`. | ||
|
Uh oh!
There was an error while loading. Please reload this page.