Repository reorganization

[t-bltg]

Plots is kind of hard to contribute to (I take my example: I started to contribute about a year ago transitioning from Fortran / Python combination to Julia), because the code is split among different packages: RecipesBase, RecipesPipeline, PlotUtils, Plots, leading to the following non-exhaustive list of problems:

1. difficult to search for methods and types (with grep and friends) for understanding the algorithms;
2. ci is split becoming a potential source of dependencies failures;
3. Plots related issues and PRs are split (this is not easy for maintenance, and we lack maintainers);
4. developing requires forking + Pkg.develop each modified pkg, and mixing dependent PRs is sometimes cumbersome;
5. split documentation (not easy for the end user).

I would thus propose to integrate RecipesBase.jl, ... to Plots.jl (centralization of dependencies) as what is done in Makie, where GLMakie lives in Makie.jl/GLMakie.

The rearranged repository would look like:

• Plots.jl/RecipesBase
• Plots.jl/RecipesPipeline
• Plots.jl/PlotUtils
• Plots.jl/Project.toml
• Plots.jl/...

CI would be easily rearranged to test RecipesBase, ... first, and then Plots.
The sub-packages would remain split (same uuid, we would have to change the url in the General registry), so this should be transparent to e.g. Makie which uses PlotUtils.

The docs would have to be re-arranged too, but this shouldn't be much of a problem.
Old repositories would have to be archived (github label) and the link to the old docs removed (not sure how to do that).

I'm opening this issue to see if there are arguments that I didn't think of, which could prevent reorganization.

Cc relevant contributors: @tbreloff @BeastyBlacksmith @daschw @mkborregaard @jheinen.

[BeastyBlacksmith]

Well, the Makie situation is a bit different, since changes in Makie.jl frequently involves changes in all backends (GLMakie, WGLMakie and CairoMakie) as well.
Its like we split all the different files in backends to separate packages.

Apart from API changes and moving of functionality we rarely need to syncronize PRs between the different parts, that were split from Plots.jl. So let me comment on the different packages in detail

• PlotUtils: I'm quite against pulling that package in, since it is thought as a fundamental building block for any plotting package
• RecipesPipeline: I'm not that sure about this one. It was split from Plots.jl to allow other plotting frameworks consume recipes, but apart from some early experiments it did not really happen. So it probably could also live here.
• RecipesBase: It is somewhat neat to have recipes related issues in one place, but it is also eaasy to completely forget about them. If they would be more prominent by being swallowed in the larger amount of issues in Plots.jl? I doubt that. But semantically it would make sense to have that package here and I don't think that move would impact anybody else.

I am all in of centralization of documentation in PlotDocs.jl though, I do find it unfortunate, that we have a separate documentation for RecipesBase that is not visible from the Plots.jl documentation.

[t-bltg]

Also, the Makie.jl example is also a bit different since dependencies are reversed: GLMakie depends on Makie: it was only to illustrate the repository structure. I could also have mentioned SnoopCompile.jl as a centralized example.

Apart from API changes and moving of functionality we rarely need to syncronize PRs between the different parts, that were split from Plots.jl.

IMO, the current distributed structure is also preventing API changes and code evolution (which is fundamentally necessary if we wish to keep a project alive).

I'm quite against pulling that package in, since it is thought as a fundamental building block for any plotting package

Let me be clearer, it will still be distinct from Plots from the end user pov and it will not prevent any package from depending solely on PlotUtils, we just need to copy the dedicated README.md in the new directory along the source, test and toml files ...

It is somewhat neat to have recipes related issues in one place, but it is also eaasy to completely forget about them. If they would be more prominent by being swallowed in the larger amount of issues in Plots.jl? I doubt that

I think we have tools such as tags to categorize issues and PRs.

Anyway, just my two cents on the evolution of Plots ...

[BeastyBlacksmith]

Let me be clearer, it will still be distinct from Plots from the end user pov and it will not prevent any package from depending solely on PlotUtils

I know that, but you signal a kind of ownership of that package. People can only find that package going to the Plots repository, they can only gain direct acces by gaining direct access to Plots, etc...

[BioTurboNick]

I think @BeastyBlacksmith 's view seems like a reasonable subset of what you propose. I've often had to work between Plots/RecipesPipeline/RecipesBase to resolve an issue, but I've not yet had to touch PlotUtils.

[t-bltg]

Let's try with RecipesBase and RecipesPipeline.
Docs will follow later at PlotDocs.

[BeastyBlacksmith]

We should figure out how to configure TagBot to create github releases for the subdirectories and have it create the corresponding summaries based on certain labels. Currently all PRs are listed in the last Plots release.

[t-bltg]

Not supported atm: JuliaRegistries/TagBot#157.

[lstagner]

Wasn't one of the reasons to have a seperate repository for RecipesBase.jl was to have a lightweight package that didn't take forever to load? While we can use the archived repository for a while but eventually code drift will become an issue.

Is there a way to just load the RecipesBase.jl that lives in Plots.jl

[t-bltg]

RecipesBase is still separated from Plots, and registered as a standalone package, so could you clarify your issue ?

[lstagner]

https://github.com/JuliaPlots/RecipesBase.jl is archived and is read only. While we can use it for now eventually RecipesBase.jl in Plots.jl will be updated and the archived RecipesBase.jl will break.

[BioTurboNick]

Repository =/= package

The RecipesBase package lives in the Plots repository, but it's still its own thing, and the registry points to it.

When you do add RecipesBase, you're getting it from here. See: https://github.com/JuliaRegistries/General/blob/master/R/RecipesBase/Package.toml