Suggest conda-forge as fallback channel, not default

[Zac-HD]

conda config --add channels conda-forge inserts conda-forge as the first channel to be searched. This generally leads to the replacement of many default packages the user may not have intended to modify. (If this is the recommended approach it should be clearly explained)

Using the --append argument instead uses conda-forge only for packages not provided in the default channels, which is a more sensible default for new users. --append also clearly adds to the end of a list, where --add is ambiguous.

[jakirkham]

Hmm...personally not sure I like this trajectory. Here are my thoughts.

1. Long term conda-forge will be an independent stack from defaults.
2. Sometimes breakage already occurs when interfacing the two channels. (changing the order could give unexpected results)
3. We don't build in this new order because of 1.
4. This is going to absorb a lot of bandwidth helping users with different orderings from what we use.
5. Not clear what the motivator is for this configuration or whether it is appropriate for that

Could you please provide more info on the motivation for this change? Use cases in particular would be very helpful.

If the issue is which NumPy is used like issue ( #232 ), it seems like this solution is overkill. Maybe a discussion with conda about adding overrides to channel priority for specific packages should be had.

[Zac-HD]

Motivation is essentially the same as #232 - I use conda-forge mainly to provide packages which are not available in the default channels, and do not want to replace the rest of my install in the process.

Based on your comments, it sounds like the usage instructions should show how to set each configuration (ie --add and --append), summarize their effects, and mention why each might be desirable.

[talkaminker]

The same as @Zac-HD , this is not about numpy or not. I think for most people, conda-forge is the channel they use to install stuff when it is not in the default channel.

Also, for a new person in anaconda, running any update like
conda update matplotlib
will reinstall almost everything in their env because conda-forge will get higher priority than the default.

[ChrisBarker-NOAA]

On Wed, Sep 14, 2016 at 8:34 PM, jakirkham notifications@github.com wrote:

Long term conda-forge will be an independent stack from defaults

Really? I thought that was a "maybe someday" -- not a clear plan,

And that for now, it really is about extending defaults, not replacing it.

That being said, the "trick" is that there are times when defaults doesn't
do something "right", or doesn't' keep up with upgrades as fast as we'de
like, or....

So if conda-forge ever mirrors defaults with the same package in a n were
or better form, it's probably best that that one be found first -- thus
putting it first on the list.

Any anywhere there is no overlap, it doesn't matter :-)

-CHB

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

[jakirkham]

Really? I thought that was a "maybe someday" -- not a clear plan,

And that for now, it really is about extending defaults, not replacing it.

Nope, we sort of decided that in issue ( #22 ). But more so we have decided this in our actions in the following months after that discussion ended.

Increasingly the move has been to package more things here and not less due to ABI issues, pinning issues, what features packages are built with here vs. defaults, and generally assuming more control over our stack. Anytime there has been an issue over the last few months we have built more stuff here to fix it. Also everything is built with conda config --add channels conda-forge so we pull in as much stuff from here as possible.

We already have packaged all of the Miniconda stack and intentionally so. ( conda-forge/staged-recipes#1063 ) We are working on our own installer. ( https://github.com/conda-forge/conda-forge-anvil ) Note the plan with that is to use it in place of Miniconda on our CIs.

In the some cases, we have very intentionally chosen to break with defaults even if it comes with a cost. ( #169 )

So I can't in good conscience suggest that people merely append conda-forge to their channel list as all these old issues will resurface.

[pelson]

Thanks for the PR @Zac-HD. Sorry it has taken me so long to get back to you.

I totally agree with @jakirkham on this one. As a community we have very consciously agreed to package the whole stack, not just the packages that haven't been packaged/packaged-well in the default channel. For improved experience or operational simplicity we have made some different decisions to those made for defaults that will inevitably lead to imperfect compatibility between the defaults channel and conda-forge. That said we do package everything with the intention of being able to conda install <package> --channel conda-forge into the standard anaconda environment.

I would find it a challenge to merge anything that modified the conda-forge homepage to be significantly more verbose or that weakened the conda-forge community's ability to correctly provide packages to conda-forge users, though I'm totally up for making minor modifications that improve the usability of the documentation for everybody.

With that in mind, I'm going to go ahead and close this PR as a wontfix. I hope that doesn't discourage you from contributing to conda-forge - we are a very open community that is trying to package an entire ecosystem in a freely available, open and transparent way and would love to have your help in making conda-forge an even better place to collaborate.

Thanks!

[Zac-HD]

No worries @pelson, it was a speculative pull anyway and not much sunk effort here! Thanks also for the clear explanation - when rejection is this much fun I am indeed more likely to stick around 😄