That would make sense since we have control over what's available from conda-forge, whereas conda's defaults channel (and Anaconda) are outside our control.

I'm +0.2 on this.

The downside is that users who don't know what channels are, are more likely to use the main channel because it's the default. Then, blindly copying the conda-forge install leads to a mixed environment. People who are on conda forge are more likely to know what a channel is and can adapt the call. OTOH there may be enough blind copy-pasting including -c conda-forge from other places that some people without channel-knowledge get the correct version by going to conda-forge.

What are others doing:

• numpy elegantly goes around this by creating a new environment. That's clean, but maybe also not what people want. And it needs a couple of lines of code, not just one.
• scipy only states conda install scipy
• pandas only states conda install pandas here and has a very unhelpful additional Download Anaconda

So another option we can do that's bulkier but probably more 'correct' is keep conda install matplotlib but add something to the conda install tab about conda not always having the most updated matplotlib and then they can install from conda-forge (with a link to their page so they can explain what they are) and conda install -c conda-forge

Edit: we kinda do that in the see more https://matplotlib.org/devdocs/users/installing/index.html#third-party-distributions

That would make sense since we have control over what's available from conda-forge, whereas conda's defaults channel (and Anaconda) are outside our control.

There is an internal Anaconda process for requesting a package build on defaults channel. I'll request a build of 3.6.2 and we can see how long it takes. In future someone could ping me when they want a new build.

Matplotlib 3.6.2 was released on conda defaults channel today (https://anaconda.org/anaconda/matplotlib), 27 days after I requested it. I think the process will be faster next time without any intervention, and it might be possible to speed it up further by providing some help. But I would entirely understand if mpl maintainers concluded that this is too slow and that the advice to users should be to stick to conda-forge.

If I remember correctly, there are also certain terms of service requirements when it comes to using packages from the Anaconda defaults channel. I'm not saying I have problem with those, but I think it at least bears some further thinking.

Unfortunately, there is no universal recommendation that would match all users / use cases. anaconda and conda-forge are two distinct package sources with different boundary conditions.

Maybe the best way ist to turn this into three tabs: pip | anaconda | conda-forge

Each tab can get an additional sentence describing some context.

The downside is that only one is displayed at a time and we have to give one (pip) the priority of beeing initially shown. But that would be ok for me.

I think my conda defaults investigations have held this up, and I don't want it to stall forever. So I would be inclined to opt for @story645's original suggestion of showing two options: pip install matplotlib and conda install -c conda-forge matplotlib.

I don't think we can justify giving equal billing to conda install matplotlib. We could reconsider this if/when there is a tried and tested process in place to update conda defaults on each new matplotlib release.

this seems pretty straightforward now, can i get to it? 🤠

Fixed by #24888.