| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
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.
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.
| Back | FazBrowse Home | New Git URL |
Documentation Link
https://matplotlib.org/devdocs/
Problem
Our install instructions say to install from conda, but conda's version of matplotlib isn't always the latest. For example:

But this won't work because the latest version of matplotlib on conda is 3.5.3, which is not obvious unless you know to look at the page.
Suggested improvement
Maybe we should change it to conda install -c conda-forge matplotlib since we can ensure that will work?