StatPlots has just changed it’s name to StatsPlots. This means that to keep using the package (on julia 1+), you will need to
]rm StatPlots
]add StatsPlots
If you have any tutorials using StatsPlots, please change the name in there as well.
The change happens for consistency with the JuliaStats ecosystem, that has StatsModels, StatsKit, and the other plotting package with similar goals, StatsMakie. This reflects that a design goal of StatsPlots is to provide recipes for all statistical types defined in packages included by StatsKit, so that people can plot regressions, clusters, PCAs etc. seamlessly, and that StatsPlots will take on dependencies on the Stats packages to do so.
Note that we are aware that this is not the best design for such functionality. A much ligther design would be for the packages defining the types to take a dependency on the very small non-interfering package RecipesBase (400 loc with no dependencies and no exported names, which only changes along with julia minor versions) and defining recipes for the structs.
The StatsPlots approach reflects our conviction that statistical objects must have plotting functionality defined. And if the better light-weight recipes approach is adopted in the future it would be very easy to port the functionality to StatsKit or the individual stats packages.
In a similar change, we have refactored the PlotRecipes to only contain graph-related recipes (other recipes have been moved to StatsPlots) and renamed it to GraphRecipes.
(v1.1) pkg> add StatsPlots
ERROR: The following package names could not be resolved:
* StatsPlots (not found in project, manifest or registry)
Please specify by known `name=uuid`.
Does this change take some time to filter through?
The old StatPlots.jl also had issues where it was tough to do a using Plots prior to the using StatPlots since it was re-exporting everything. Has that been removed in this or recent updates?
This is my issue. Why does it reexport a common dependency that people are likely to already have loaded? I have never run into this before, and I use a lot of packages. Maybe they reexport hidden “Base” dependencies people would never include directly, but I can’t think of an example where they reexport a commonly used dependency likely to be in the code.
Imagine the usage scenario, which I am doing all the time… Load up Plots.jl close to the top of my notebook or code. Maybe even do the using Plots compiled into the image from @sdanisch and Plots Environment - Nextjournal as soon as I can…
Then I decide I want to use some Stats recipes. Why does that need to break all of my existing code?
Is it essential to the architecture? Because it is an annoyance rather than a feature. If the solution is simply "don’t reexport and tell people they need to replace existing using StatPlots with using Plots, StatPlots, I think that is a minor impact on users.
I can confirm at least the initial issue is no longer a problem. We can test if there are any more issues with loading Plots before StatsPlots, but for now it could be that the issues have been resolved silently.
@jlperla this is needless hyperbole. using Plots, StatPlots has never broken all of anyone’s code. There has been a very few niche cases like the one @Nosferican posted where loading the package and issuing plot statements in a specific order caused a few recipes to work less well, that’s all.
StatPlots reexports Plots because it’s intended as an alternative larger package for those that don’t mind having the Stats packages too. So there’s no reason to do using Plots; using StatPlots and that’s all you’ve been told. Do it if you must, by all means, I don’t care.
Instead you’re taking over a discourse issue on something completely unrelated with hyperbolic descriptions of a non-existing problem you have, and a requirement that we reimplement the entire package to accomodate it. This comes with no associated desire to contribute, you’ve not even opened an issue about it with an MWE.
You are asking everyone to go back and change their using StatPlots in their code, so it is a reasonable time to ask if we can also change this to using Plots and then using StatsPlots as well. If you think I should have posted separately, I apologise.
Sorry, I think you misunderstood the tone of me walking through a user experience. No hyperbole intended, just trying to convey the confusion that I (and other people would have) in running through lecture notes if they had already done a using Plots and can’t figure out why StatsPlots won’t work.
The problem is that “niche” case is the only one I had ever run into. We had people carefully testing dependencies and trying to patch them where possible.
There was a posted minimum working example, carefully tested in a publicly accessible piece of code… I had @arnavsood and @Nosferican test it and try to come up with fixes, but they told me they were unable to do it without you because of the architecture of the package. They posted Broken for Distributions? · Issue #195 · JuliaPlots/StatsPlots.jl · GitHub to discuss with you to verify the problem, and you responded
The solution in the longer run will most likely be to not reexport Plots, and thus require you to load Plots.
This isn’t me asking you to rewrite a package, but rather checking in to see if you had done what you had said you were planning to do. The answer could simply be “sorry, didn’t get around to it or I changed my mind… or lets discuss this in another thread… or could use some help”, but I don’t understand the need for an attack.
Regardless, we will retest this to see if the initial issues how now been fixed through some other change. Perhaps your idea to “not reexport Plots” was not the only way to solve it.
Hi @jlperla if you are involved in this issue then I apologize for saying you didn’t open one - I didn’t realize you were behind this, so that was unfair.
And sorry for reacting so strongly - it was simply the gap between the actual inconvenience (I believe the issue was only ever with plotting Distributions when loading packages in the order Distributions, Plots, StatPlots), your description of the problem (“break all of my existing code”) and the requested fix (reimplement the package).
I didn’t realize it at the time of commenting on the issue, but a few days after it was opened I spent most of a day trying to make StatPlots Plots-independent, and ended up running into various issues, realizing how big of a rework it was and dropping the idea. So the idea of making StatPlots Plots-independent has been abandoned.
Reexporting Plots was never a temporary hack - it was part of Tom Breloffs philosophy that StatPlots should be the package of choice for people using statistics, instead of Plots. I very rarely just do using Plots myself. I guess the relationship can be redesigned (like we did for Plot/GraphRecipes which is now Plots-free), e.g. today the Tables interface is so light it should probably just live in Plots.
I’ll add that I have no idea why the problem disappeared, it’s certainly not due to a change in StatPlots - one guess might be that julia has become better at cache-invalidating compiled methods?