-
-
Notifications
You must be signed in to change notification settings - Fork 287
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
Update download.jsx to mention pixi #2465
base: main
Are you sure you want to change the base?
Conversation
While still under active development pixi-build should be mentioned.
✅ Deploy Preview for conda-forge-previews ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
I'm wondering if mentioning |
I think |
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.
There is one canonical installer which is miniforge.
pixi, micromamba, conda, mamba are tools which can use conda-forge packages. This distinction is not made here. If you are adding pixi here, we should add micromamba, conda, mamba as well.
Why is Given that micromamba and pixi do not have these dependencies miniforge seems like it would be more confusing than helpful. But maybe that is just me. I have no problem adding in descriptions for micromamba, conda, mamba as well. |
Because that's the only installer produced by conda-forge. Others are related and influenced by conda-forge, but not fully part of conda-forge. |
So, the significance is that when doing things which are blessed by conda-forge the expectation is that miniforge will be used? I am thinking of something like processing a feedstock. What has me confused is that miniforge is canonical but the things it installs are not canonical. |
While
pixi-build
is still under active development it should be mentioned as aconda-forge
installer.