Dependency on maggritr and purr

[pommedeterresautee]

For comfort reasons only I have heavily used these two packages.
I can easily remove them, it will make the code less readable and longer.

However, we have too many dependencies right now, and the package is still small. Some of them will probably break in the future (Harvey packages have beautiful API but a tendency to evolve in the long term) and so on... (it also explains why I want to remove the other dependencies).

So, what do you think about cleaning the package?
It may happen after the change the API you have planned.

[thomasp85]

I never really use magrittr and purrr (and very seldom dplyr - I was apparently lazy here) when developing packages.

I accepted that you wanted to use pipe and purrr, but if you want to remove them from your code I'll be very supportive.

I think the notion of "too many dependencies" is a bit strange though - if a package is used for a valid reason I have no problem including it. If you are more comfortable programming with purrr, I think that's a valid reason...

[pommedeterresautee]

I answer here for both #17 and #20.
There are few reasons why I think it may be good to reduce the list of dependencies:

• one is from my own exp when writing the XGBoost R package. I made lots of dependencies, in particular on some Viz packages. Viz package author broke the API every 2 months, making it more complete and more complexe. So every 2 months I had to learn the new API and update the package. Very annoying with lots of issues opened because people had a working package and because of update, everything was broken.
• some dev really hates the hadleyverse for bad/good reasons (I really don't care). Even if we may think tibble offers a better API or a better print, if we don't really need its features, we should not force the user to follow our opinions (I know it s easy to convert to other format). If vanilla data.frame make the work, why we would not use it? (it would be another story if you think to use its features in the future, for instance on XGBoost I only use data.table for its speed in join/select)
• regarding purrr in particular, it offers a very nice API for someone with a functional background but may discourage other dev to enter in the project just for my own comfort. So I think it s better to remove them.

Please don't hesitate to share your mind, I would be very interested in it.

[thomasp85]

I currently maintain ~15 packages and seldom have problems with changing API's (just to share my personal experience). I have no problem removing tibble and your point is valid so consider that done. I would be thrilled if you removed pipe use in the text-explainer as I prefer its use during analysis and not within packages, but being a collaboration I am also OK with others using their preferred approach. The same goes for purrr.

[pommedeterresautee]

done/closing