Roadmap -- JuliaPlots #222
Comments
|
Ref for changing repo URL: JuliaLang/METADATA.jl#649 |
|
By popular demand:
|
|
I went through the chat history to understand this better. I see the motivation. I am a little confused about you proposing to move your biggest baby away from your personal account. Have you thought that through? You can always do this at some later point when you lose the time or interest to put so much effort into it. Personally, I see the ability to move a package to an organization as a tool for different agendas
On the contrary I also think having a package in ones personal account has the advantage of perceived sole ownership. For some reason one feels a lot more responsible for his/her own packages. Maybe because the github landing page feels a little like a portfolio and there is always this thought lingering that people might look you up and browse through your Popular repositories. so you want them to be nice and clean Regardless. Moving a package isn't that difficult. the Metadata entry has a link that needs to be updated, so thats trivial. The most annoyances are travis, readthedocs, and coverall, but they aren't difficult, they are mainly just annoying and take some time to set up. Concerning MLPlots: I think MLPlots should exist on its own as part of JuliaML and at least contain ML focused plots; especially for the packages in JuliaML. I do get the motivation for PlotRecipies and I also think it should exist. It does make more sense to me though that domain specific things should be closer to it's real domain. That seems a lot easier to maintain and also easier to stay interested in maintaining in the first place. |
My biggest baby is downstairs learning to crawl right now ;) But seriously, I am with you on hesitations about the weakening the connection between @tbreloff and Plots.jl. I want that association to stay, but that reason alone isn't compelling enough. More important to me is not giving away commit access to the core of Plots. I'm just not ready for anyone else to make decisions regarding API/internals without my approval, which is why I think it makes more sense to start JuliaPlots (instead of moving to JuliaGraphics) where I retain veto power on the core. The idea is that Plots.jl would still be my baby (for the time being) and that I would be the "owner" of JuliaPlots. Any non-core aspects of the ecosystem would be broken away from Plots.jl into packages and I would give commit access to those packages for collaborators. This way I don't need to approve all backend-specific code, or recipes, or themes, but I do have to approve anything that affects the core API and internals.
I don't want to wait for this moment before making a move, as then I won't be able to transition it well.
Actually I think this is the main draw, and there's still a big gap between the people using/watching this repo vs the core devs approval/inclusion. Much of the organization problems could be solved if Plots was part of the julia "standard library" and package authors could be confident that most users would have it installed. Then package-specific visualizations (like those in MLPlots) could live inside the packages, not in a separate "recipes" package. The main thing preventing that is the core devs don't ever want packages to depend on graphics (even though pretty much everyone uses plotting software of some kind). I think moving the ecosystem away from my account increases the chances of making Plots a standard and officially-sanctioned package which many other packages depend on.
Like I said... in my ideal world MLPlots wouldn't really exist either because the plotting routines would live in LearnBase, OnlineAI, etc. But as a stop-gap measure I'm ok leaving the ML-specific routines there (and still having a PlotRecipes.jl for anything else). |
+:100:, I've seen this happen way too often, and the situation is pretty terrible because if no one is available to bless new maintainers, even forking the repo is not an attractive prospect as there's no guarantee of buy-in from the current users (not to mention it fragments the userbase). Besides, having an organization makes it clear who its members are, whereas IIRC there's no way to see who has collaborator access to a repository, which is important so that contributors can know who to reach out to, ping, etc. |
|
In the end it is your decision. I do get your argument, but ultimately the idea of yet-another-graphics-org seems counter productive on it's own. especially given the existence of JuliaGraphics where Immerse is.
It is not that simple I'm afraid. Just think how minimalistic UnicodePlots is and yet even you were very hesitant to have it as a dependency in LearnBase for show methods. And UnicodePlots doesn't even have dependencies. Bottom line: I do not know what the answer is but it needs a very very clever solution to achieve what you are after |
You got me there. Plotting will always be contentious I suppose, and maybe it's wishful thinking that there will ever be a "standard library" plotting option that people can get behind. But... if people were forced to pick, it would be Plots, right?? ;) |
|
I think most packages shouldn't depend on a graphic package but should instead emit data that is easily visualizable by any graphic package. This doesn't only decrease dependencies, but it also makes everything more generic ;) |
Personally I think it's less about contention and more about the perfectionist (and minimalist) tendencies of people interested in writing optimized code. The Julia community seems to attract many such people and I am considering myself as one of them. Furthermore, the design of Julia's package manager does promote the idea of having little islands of functionality that follow the "linux school of thought" of doing one thing only but one thing right. The package manager still has it's flaws but I did learn to like it |
|
I wonder. How minimalistic can you make a package that defines everything needed to create custom |
💯 This is a really good idea! I want to think through the details of how this will work and add this to the restructuring plan. Also I added a |
|
Plots is already minimal, but having a smaller option for package developers sounds good. |
|
my personal tip: it should be as minimal as possible to promote adoption (every line counts). There should really be no dependency (not even colors or requires). If this can be done I am confident we can get the ball rolling with the state plots is in. I certainly would build it into the packages I am the maintainer of to help gain momentum |
|
Agreed completely. This will be the first package that I add to JuliaPlots... absolutely minimal to allow recipe definitions for external packages. I'll post when I have something usable, and add it as a dependency to Plots. |
|
One more thing I would consider important for wide spread adoption is a good way of testing the custom plots. The visual regression tests already take care of it for the most part but what I would still be unhappy with from a userstandpoint is the default huge size of the refimages. These more or less bloat the githistory. Is there a clean way to make the reference images by default really small and neatly compressed while still containing the relevant information? |
|
Another great idea! Automatic compression/decompression as part of On Friday, May 6, 2016, Christof Stocker [email protected] wrote:
|
|
I am sure a lot could be achieved by a good deterministic way of downscaling the images |
|
to pick up from way above... Yes, i could provide maintenance for a ColorMaps.jl if needed; i'd not claim that i'll be better than other choices, maybe i have a little bit more overview, as i did something similar for a research project once. I cannot really see the need for another julia graphics/plots/plot organisation as https://github.com/JuliaGraphics/ and https://github.com/JuliaPlot/ already exist (and even that could be converged into 1 organisation only). Still (especially now after the ShowOff + Gadfly + Compose incident) i'd rather like to see infrastructure packages (and Plots as mediator between common API and a list of backends is very clearly infrastructure) as shared development. Not only to provide diversity if an owner isn't available for accepting a PR. Diversity is always a source for new inspiration - but this can also be provided by enough github discussion. |
|
I think the plan is to delete the old JuliaPlot. Generally speaking I agree about JuliaGraphics, but practically speaking I do see a strong case for JuliaPlots existence. Bluntly put I see it like this: Tom continuously puts a lot of effort into improving Plots.jl for a long time now, and egoistic me would like it if that momentum continued for a while. Having a strong sense of visible authorship and control can have a powerful influence on ones motivation to spend significant time on something, so I think JuliaPlots is a decent compromise for a transition between sole authorship and community project. So, yes, in a simple world it would be better to just use JuliaGraphics for this, but the world is not that simple |
I really go back and forth on this one. Right now, my perspective is that JuliaGraphics is the better place for drawing-type package (like Compose, Colors, etc). A ColorMaps.jl should probably live there as well. I would like to see "data visualization" packages tend towards JuliaPlots, but that's probably wishful thinking in the short term. JuliaPlot should be removed... there's really nothing there but a few issues that contain some discussion from a year ago.
For now I haven't made a decision on what to do with core Plots... it'll stay at tbreloff for the time being. I do, however, want to pull out some pieces from within Plots and make them independent projects. The first of those is RecipesBase.
This sort of scenario is very much on my mind, and I think eventually core Plots will be more of a community effort, but for now I'm too actively involved and I'm just not ready for that. You have my promise that I'll give others write access if I'm not able to spend time on the project. |
|
Just trying to follow the discussion: what incident? |
|
In a nutshell, Dan Jones went MIA, and he is the only one with commit access to ShowOff, a Gadfly dependency. As changes needed to be merged, everyone scrambled to fork it and point METADATA to the fork, and caused a lot of hemming and hawing about what to do. |
|
Talking of color maps, how many ways are there in Plots to specify a range of colors? While adding some examples for ColorSchemes I noticed |
|
Those are all different. "c" is an alias for "seriescolor", "palette" is a On Saturday, June 4, 2016, cormullion [email protected] wrote:
|
|
I think this is stale, and might be closed. |
This issue continues the discussion from https://gitter.im/tbreloff/Plots.jl. Summarizing, there are a few goals that could be achieved through a repo restructuring into a new organization.
There exist a couple possibilities of organizations to join, but I would prefer to maintain sole ownership over core Plots.jl for the time being. To that end, I propose forming the new organization JuliaPlots, of which I am the owner, and creating teams of collaborators for sub-systems of Plots:
My opinion on what should happen next:
Transfer tbreloff/Plots.jl to JuliaPlots/Plots.jl(maybe another time)Update METADATA for Plots (what are the necessary steps??)And there are some things which I think would be good for the long term, but don't need to happen soon:
Everyone, please let me know your thoughts.
cc: @spencerlyon2 @diegozea @jheinen @Evizero @dlfivefifty @timholy @pkofod @SimonDanisch
The text was updated successfully, but these errors were encountered: