Naming issue with defaults

[ocefpaf]

I would like to bring to the @conda-forge/xgboost maintainers that this package is named py-xgboost in defaults. I don't really care about the name but it would be nice to sort the confusion out somehow. Pinging @msarahan who can explain the reason behind the naming in defaults.

More on this discussion here:

https://gitter.im/conda-forge/conda-forge.github.io?at=5bae19c27bd81c5b9dc89c59

[msarahan]

May I humbly suggest that we add an xgboost metapackage to the anaconda recipe for name continuity, but otherwise merge the Anaconda recipe in here? If this repo is ready for a compiler migration, we can do that.

[beckermr]

Hi friends! I noticed the defaults package forked this one and then added a fair bit of new stuff.

I am happy to take on merging the changes from defaults back here. I am a bit confused on some things.

1. What exactly would the metapackage on defaults do? Just install py-xgboost and its deps?
2. When will I know if this repo is ready for compiler migration? Does the bot make a PR?
3. Do we really need two recipes in the world?

[msarahan]

1. Yes, it's just to maintain consistent behavior with your existing packages
2. Yes, the bot will make a PR. It is done in dependency order, so some of your upstream dependencies still need to be built before the bot sends a PR here.
3. Unfortunately, I believe so. We hope to get to a point where the AnacondaRecipes fork is in-sync with the recipe here, with perhaps only tiny deviations required for our corporate purposes. This repo on conda-forge should be considered authoritative, and Anaconda should contribute directly to it for anything other than modifications that we need but the community does not want.

[beckermr]

Ack. Missed the update. I will start a PR and then move on from there. Thanks!

[jjhelmus]

I should also point out that defaults also has GPU accelerated variants of xgboost in the py-xgboost-gpu and r-xgboost-gpu branches.

To prevent users from accidentally installing both the GPU and non-GPU variants of the package (whose files would clobber each other) the GPU packages use the same names as the non-GPU packages, py-xgboost and r-xgboost. A mutex/selection packages, _py-xgboost-mutex and _r-xgboost-mutex, is used makes the non-GPU version the default, so a users running conda install py-xgboost will get the non-GPU variant. To install the GPU variant users need to install the meta-packages, py-xgboost-gpu and r-xgboost-gpu.

The non-GPU variants also have metapackages, py-xgboost-cpu and r-xgboost-cpu for users who want to be explicit about the variant they install.

If the recipe here could add a run requirement on _py-xgboost-mutex = 2.0 that would alight the the layout with the version in AnacondaRecipes although I do not believe this is necessary.

[beckermr]

My plan was to copy-paste the defaults recipe wholesale (assuming licensing allows it) so that everything is synced. Then I was going to add the metapackage. I am not following the mutex discussion above or your comments, but I can def add that line to the run section.

[jjhelmus]

Coping is fine, if you need help with the multiple outputs or the mutex feel free to ping me on the PR.

[msarahan]

probably better to do a git merge, so you keep the commit history from Anaconda

[beckermr]

Will do @msarahan. Thanks @jjhelmus! I may tag you for code review.