-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Dealing with proliferation of package variants vs. ease of selection #1558
Comments
Yes virtual packages. Particularly custom ones for extensibility ( conda/conda#10131 ). They can detect system features, which either allow or disallow particular variants. |
Virtual packages are not the answer to everything though... A virtual package IMO makes sense for something (effectively) immutable like OSX, CPU Arch, GPU version, but not for things like BLAS, MPI, OpenMP, etc... And even with virtual packages, I might want to override them and install the CPU version despite having a GPU, or install the SSE version despite being AVX2-capable. |
Though looking closer at conda/conda#10131, maybe I'm overlooking how the plugin-approach might overcome these issues/limitations? If so, could you elaborate? |
Mainly thinking about auto-detection and constraint of OS and hardware features. With the existing virtual packages there are already ways to override these. Presumably that could be done for new ones The other things (BLAS, MPI, etc.) are up to the user to decide. What alternative would you propose? |
My point was exactly about exposing these variants to the user, and ideally in a more user-friendly way than pattern-matching build strings. I have nothing against package variants, I think they're a great asset of conda-forge. I just wish we'd have a better UI for it. |
@ngam, this might be best as a new issue on the webpage (this) repo (though it does seem like an interesting discussion to have) |
It's diving deeper into CUDA functionality. We may want to invite others familiar with that use case to discuss further. While generally within this issue, it is a bit of a subcase. So we may not want to get too into the weeds on that case in this issue (and so move it to another one) To be clear am happy to see that discussion move forward, just trying to keep things organized |
FWIW the virtual package plugin architecture is being worked on in PR ( conda/conda#11854 ). Once complete virtual packages could be created independently and used as dependencies in metapackages to cutdown on the configuration users themselves would have to do. |
Crossposting from conda/conda#11053 because it affects conda-forge in many ways.
I opened that issue on conda to find out if there might be a better solution than tacking on more and more things onto buildstrings. 😅
The text was updated successfully, but these errors were encountered: