-
-
Notifications
You must be signed in to change notification settings - Fork 280
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
multi-output: document full/lite splits with optional dependencies #2168
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for conda-forge-previews ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
16ecfb6
to
77b9535
Compare
@@ -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 comment
The 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:
- Add the run_constrained pin_subpackage problem to the pitfalls (link to issue).
- Add a shorter summary of the solution you are proposing to the aforementioned list to avoid duplicating information. Briefly warn about the pitfall here.
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 comment
The 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 Distributing the same project with different sets of dependencies
. Hmm...
Co-authored-by: jaimergp <[email protected]>
PR Checklist:
docs/
orcommunity/
, you have added it to the sidebar in the corresponding_sidebar.json
fileSeems to have been done a couple of times already, but was a bit of an adventure for me, so maybe worth putting it into docs.