Cairo Dependency
samuel-marsh opened this issue · comments
Hi,
Thanks for creation and dev of this package, it’s super useful!! This issue is actually a question regarding your thoughts on package dependencies, specifically the Cairo package.
Unless I’m mistaken the only direct use of Cairo is in setting the dev param (where it is the default).
#' @param dev string Specifies the device used, which can be one of: \code{"cairo"}, \code{"ragg"} or \code{"ragg_png"} (default="cairo").
I’m wondering whether you might consider moving Cairo from Imports to Suggests and implementing a package check in the functions to set the dev param vs having a blanket default. I know Cairo is fairly common package but the number of packages with reverse imports on CRAN is actually fairly low and Cairo appears to be very common cause of installation issues (either first time installation or during upgrade of R versions). Also simplifies installation for people in locations where they may not have sudo privileges (HPC clusters, company servers etc) where it becomes more complicated to install underlying system level libraries needed by Cairo
Here is example of package check type mechanism I was thinking (in this case it’s actually checking for ggrastr which avoids taking ggrastr as direct Imports):
https://github.com/satijalab/seurat/blob/a1294c4d363780548dbf9cc4a4abb3a6078a6d64/R/visualization.R#L7243-#L7253
I totally understand if your preference is to remain a direct Import but just wondering if that is something you might consider?
Thanks again!
Sam
We could review a PR if you implement this.
For each function, we'll need something like:
if (!requireNamespace("Cairo", quietly = TRUE)) {
stop("Package \"Cairo\" needed for this function to work. Please install it.", call. = FALSE)
}
given this is a default parameter.
In terms of this:
Cairo appears to be very common cause of installation issues (either first time installation or during upgrade of R versions). Also simplifies installation for people in locations where they may not have sudo privileges (HPC clusters, company servers etc) where it becomes more complicated to install underlying system level libraries needed by Cairo
I guess I just find this logic a bit difficult to swallow
https://www.cairographics.org/download/
https://en.wikipedia.org/wiki/Cairo_(graphics)
There are many R packages which have external dependencies. I think Cairo is a common one for complaints, as it's a graphics library which R users use for plotting and maybe it's the first time they interact with this problem: https://stackoverflow.com/questions/16678934/r-cairo-installation-without-apt-get-sudo
All of the packages at https://github.com/kharchenkolab/ will require some sort of external dependencies which need to be installed.
My response to this has always been to speak to your HPC system administrators.
The reason concern expressed here by some R users is that they wish these external C/C++ libraries didn't exist, or weren't such a pain to work with. Why do we have to compile this stupid code, when it's so easy with install.packages()? Yes, that's true....compiling C++/C is a pain and without sudo making system-wide libraries is not easy. This is why we have system administrators and Docker/Singularity, and why tools other languages designed easier methods for installing tools.
@samuel-marsh , yep, the PR would be very welcome :)
@evanbiederstedt , there are actually surprisingly few packages that import Cairo, I thought this number would be much higher.
@VPetukhov
The problem is that we've always included cairo as the default parameter. So it's technically not a backwards-compatible change.
Does it matter? Not sure. We probably should have used ragg as the default: https://github.com/r-lib/ragg
We probably should have used ragg as the default:
I thought about it when these parameters were just introduced, but on my personal tests ragg quality was visibly bad, so I kept it as is. :)
So it's technically not a backwards-compatible change.
Well, if we only change behavior in case Cairo is not installed, then it's not a breaking change: that usecase was already broken. If @samuel-marsh decides to pursue that, I'd just bump version to 1.1 and call it a day.
I thought ragg wasn't great either when I tried.
Well, if we only change behavior in case Cairo is not installed, then it's not a breaking change: that usecase was already broken. If @samuel-marsh decides to pursue that, I'd just bump version to 1.1 and call it a day.
Default is cairo. If Cairo not installed, throw warning and use ragg?
Fair enough. If there's a PR, we'll review
Hi Guys,
After hearing your thoughts and previous experience and trouble shooting the installation issue user had with my package (due to ggrastr import) I'm happy either way. I'm going to work in future to set up docker for my package with Cairo installed so there is work around in case anyone has issues with installation
I also agree that most installation issues are easily solved with some googling and StackOverflow. Therefore I'm, happy to leave this as is if you'd prefer Cairo remain as Imports so that users get the best visual experience (which I agree is important when dealing with raster images).
I can write PR and see what you guys think.
Just let me know which way you are leaning.
Thanks!
Sam
@samuel-marsh , I'd actually prefer having Cairo in Suggests, if it's done in a way that for users with Cairo installed we keep the default dev="cairo" and throw a meaningful warning otherwise. Thank you for the help offered!
sounds good I'll work on PR this week! Just confirming I'll fork from the master branch? Appears the develop branch is couple commits behind master.
sounds good I'll work on PR this week! Just confirming I'll fork from the master branch? Appears the develop branch is couple commits behind master.
Please make the PR against the develop branch
Thanks for the help here, @samuel-marsh . Please add Viktor and I as reviewers.
Closing as this wasn't touched