search

thomasp85 / tidygraph

A tidy API for graph manipulation
https://tidygraph.data-imaginist.com
Other
546 stars 61 forks source link

Requesting to move the activate() generic to the generics package #137

Open krivit opened 3 years ago

krivit commented 3 years ago

I am one of the collaborators on the egor package for manipulation and analysis of egocentric network data. We are trying to pare down the hard dependencies of the package, particularly those that have many hard dependencies in turn.

The main reason egor currently depends on tidygraph is for the activate() generic. (In our case, the active units are egos, alters, and alter-alter relations.) However, tidygraph depends on igraph, which is a large package that has additional build requirements.

We were therefore wondering if you would be amenable to contributing the activate() generic to the generics package and depending on thati. I would be happy to be the go-between and to make the needed pull requests.

thomasp85 commented 3 years ago

Yeah - the plan has always been for activate() to become more general and I think it makes sense to put it in generics

krivit commented 3 years ago

Great! Shall I raise the issue in r-lib/generics?

thomasp85 commented 3 years ago

Just chatted with Hadley about it and it is out of scope for generics so we'll have to find another solution

krivit commented 3 years ago

Thanks for following up! I had forgotten that you are coworkers.

I am a bit surprised, since tidygraph is a tidyverse package, and egor, while not a part of the tidyverse, implements most tidyverse verbs for it.

One option is to create a new package, e.g., graph.generics. There is, in particular, a number of methods with the same names exported both by network and by igraph. (The latter was forked from the former a long time ago, though they have diverged substantially since.)

Or, would it make sense to fork generics into, e.g., more.generics for a package that has the same functionality, does not overlap with generics, but has more liberal inclusion rules? (As far as I can tell, the cost of each additional generic is less than half a kilobyte of uncompressed package size.)

Another, and this is a much bigger ask of you, is to make tidygraph Suggest: igraph---so that if the user only wants the data management functionality, they don't need to install it.

What do you think?

tilltnet commented 3 years ago

Hi, I am another author of the egor package.

Yeah - the plan has always been for activate() to become more general and I think it makes sense to put it in generics

I like the idea for a more general placement of activate(), it would be a helpful tool to work with any kind of a list of tbls or data.frames. So another option could be to create a tbllst ("tibble list") package, that provides the activate() generic and methods for dplyr verbs. I have vague plans (and some specific ideas) for such a package and wanted to toy with this idea for a while.

At the same time I think a liberal version of generics would be a nice thing to have.