search

dahtah / imager

R package for image processing
GNU Lesser General Public License v3.0
187 stars 43 forks source link

Reduce the number of dependencies #70

Open Bisaloo opened 6 years ago

Bisaloo commented 6 years ago

Hi and thank you for your package!

You are using a lot of dependencies which makes the installation of this package (and all reverse dependencies!) very long. Even when some packages (such as magrittr or stringr) provide some convenient functions, my view is that base R should be used as much as possible in packages. This is especially true for a package such as imager that may serve as a low-level library for other packages to build upon.

For example, all stringr functions could be replaced by grep and gsub.

I don't necessarily expect you to do this change yourself. I am opening this issue to ask whether reducing the number of dependencies is something you would be interested in. If so, I could try to submit a PR in the next couple of months.

Bisaloo commented 6 years ago

Recursive dependency map as of imager 0.41.1

rplot09

dahtah commented 6 years ago

You're right, it's a very good point. Getting rid of stringr should be easy enough. I can make igraph an optional dependency as well, I think, it's not essential at the moment. readbitmap can be removed as well, by compiling cimg with libpng and libjpeg enabled (more work to do on the configure script, though). Dependency on plyr is mostly a left-over from early versions of imager and can be phased out. From your graph it looks like purrr pulls a lot of stuff along, and I'm not sure about getting rid of purrr. For one thing I expect most installations of R to have the tidyverse stuff installed. For another it's a really convenient package, even when used internally. Another issue is compile time, which could be reduced by just sticking everything into a single source file, so the compiler doesn't have to recompile all of CImg's templates from scratch every time.

Bisaloo commented 6 years ago

Looking at the graph again, it's no use removing stringr if don't remove purrr (and magrittr and igraph) as well because of paths like those:

imager -> purrr -> magrittr -> stringr

imager -> igraph -> magrittr -> stringr :(

I will try to have a look at less connected nodes but this reduces a lot the number of dependencies we can safely remove.

Bisaloo commented 5 years ago

I misread the graph above and it looks like stringr could be removed. Would you be interested if I made a PR to replace all stringr functions by base equivalents?

Useful resource: https://stringr.tidyverse.org/articles/from-base.html