-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
[WIP] Use one metapackage for CPU/GPU #35
base: main
Are you sure you want to change the base?
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe:
|
b908087
to
56727fb
Compare
This is ready for review! 😄 |
Based on discussions with the xgboost developers, it appears that only the C++ library changes based on whether it is built in CPU or GPU mode. The other language bindings do not change based on whether this functionality exists or not. So drop all of the per package mutexes to streamline things a bit.
…nda-forge-pinning 2019.10.22 Now that the per package CPU/GPU mutexes have been dropped, re-render the feedstock to update its content accordingly.
As only the C++ library changes between CPU and GPU builds, add a meta package to allow selection between the two builds of the C++ library. Since this does not include GPU builds yet, simply set the selection package to CPU only.
…nda-forge-pinning 2019.10.22 Now that `xgboost-proc` has been added for CPU/GPU selection, re-render to update the feedstock content accordingly.
Rebuild all of the packages now that the CPU/GPU selection metapackages have been restructured.
b9565bf
to
07b7095
Compare
This setup will create a mutex for the cpu and gpu variants for xgboost but lacks a method for establishing a order between these variants. The selector/mutex package can also establish a default package (which one is a matter of debate) either by the version number or by attaching track_features to the lower priority variants. Additionally, dropping the One might possibly renaming the mutex from |
@jakirkham Should we revamp this one now? |
We could do that. Is there still interest in this change? |
@conda-forge-admin, please re-render |
Hi! This is the friendly automated conda-forge-webservice. I tried to rerender for you, but it looks like I wasn't able to push to the use_one_mutex branch of jakirkham-feedstocks/xgboost-feedstock. Did you check the "Allow edits from maintainers" box? NOTE: PRs from organization accounts or PRs from forks made from organization forks cannot be rerendered because of GitHub permissions. Please fork the feedstock directly from conda-forge into your personal GitHub account. This message was generated by GitHub actions workflow run https://github.com/conda-forge/xgboost-feedstock/actions/runs/5473614584. |
…nda-forge-pinning 2023.07.06.05.56.46
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe:
|
…tream_6 Merge `conda-forge/main` into `rapidsai/main` (pt. 6)
Based on discussion in issue ( #23 ), it seems that CPU/GPU selection matters mainly for package size and only really affects the C++ library. Given this information, this simplifies the recipe to have one metapackage to select between CPU/GPU builds. Note that we have not added GPU builds in this PR, but hopefully this should simplify the process of adding such a GPU PR in the near future.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)