Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
krivit opened this issue Jan 31, 2021 · 5 comments
Open

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

krivit opened this issue Jan 31, 2021 · 5 comments

Comments

@krivit
Copy link

krivit commented Jan 31, 2021

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
Copy link
Owner

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

@krivit
Copy link
Author

krivit commented Feb 9, 2021

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

@thomasp85
Copy link
Owner

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

@krivit
Copy link
Author

krivit commented Feb 9, 2021

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
Copy link

tilltnet commented Feb 9, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants