UpSetR

[hadley]

https://cran.r-project.org/web/packages/UpSetR/index.html

[thomasp85]

BTW A fantastic approach to set visualisation that more people should familiarise themselves with. But I don't think it falls in the ggplot2 extension camp - more a specific visualisation technique implemented with ggplot2.

There is a line between adding to the ggplot2 API and providing visualisations powered by ggplot2 underneath, but I admit that the line can get blurry at times...

[thomasp85]

How dare I disagree with the father of ggplot2 on this kind of matter 😉

[thomasp85]

Maybe there should be two sections to the site. An API extension section and a "powered by ggplot2" section. I fear that due to the success of ggplot2 the latter will be quite unmaintainable though - the reverse depends list is quite impressive

[Emaasit]

@thomasp85 I agree with you. This site is intended for packages that extend ggplot2's API; hence the name "ggplot2-extensions". There are very many packages out there that are simply "powered" by ggplot2. I am hesitant to adding them here.

[hadley]

I think this is an unnecessarily narrow definition of extension - there are many ways to extend ggplot2's API, not just by adding new geoms and stats.

[thomasp85]

I agree with you on that - gganimate is a fine example of an extension that lives outside the narrow geom/stat definition. In the case of UpSetR I don't see anything ggplot2 unless I look at the source code and there is no obvious way to add or couple other ggplot2 features to the output. This is why I consider it more of a "powered by" package though again I do realise the blurriness of that definition.

As said before I love the package and visualisation type so it is nothing against the package

[thomasp85]

Maybe you could expand on where you think we should draw the line between "using ggplot2" and "expanding ggplot2"? I'm open to being convinced:-)

[hadley]

To me it seems like the burden of proof is on you to argue why a narrow definition is important. It's not like there's a limited number of pages that you can fill up.

[thomasp85]

Mainly a matter of maintainability and clear overview. If the site is about giving overview of packages expanding the ggplot2 API (which I assume based on @Emaasit tweets etc.) then it would be a mess as well as hinder discovery if every reverse dependency should be listed.

But I don't think you want to list all reverse depends (do you?), I just think we disagree on where the line is between API extension and normal ggplot2 usage. My stance is that API extensions are additions of vocabulary to the grammar (stats/geoms/position adjustments, guides etc.), additions of styling (themes), data conversions (fortify) or functions/methods that work on ggplot objects (e.g. gganimate (this is really the blurry one for me)). I'm unsure about your definition, which was why I queried it, so we could discuss semantics rather than a specific package :-)

[Emaasit]

My intention (at-least currently) is to tract and list packages that extend the ggplot2 API in one way or another. Either by adding new geoms, stats & themes or functions that manipulate ggplot2 objects.

Here are the other categories of packages that we do not intend on tracking for now:

1. Packages that create their own objects and methods to display graphics. While these packages are great, they may not have anything to do with ggplot2 directly.
2. Packages that create their own objects and then use ggplot2 to display them. This can be thought of as "reverse-extension". While they use ggplot2 to display graphics, they don't add anything new to ggplot2 itself. (@djmurphy420 & I discussed about this last week). Maybe some time in the future we could track this category, but I am hesitant to making a decision on that now.

[hadley]

Ok, that sounds like a reasonable principle to me!