抽丝剥茧解决共享服务器的R包依赖问题（以xCell为例）

开始系统性梳理我们的共享服务器业务线的使用指南，首先我们官方团队做完善的整理，比如：玩转服务器—数据上传与下载，然后也邀请了一些用户分享真实的笔记：

事情的起因是我想用xCell分析两组患者的免疫微环境差异。于是正常地加载服务器的xCell这个R包和自己的表达量矩阵数据，并且运行xCellAnalysis。

> library(xCell)

> TPM_exp <- readRDS("./immune_analysis/TPM_exp.rds")

> xCell_results <- xCellAnalysis(TPM_exp,

rnaseq = TRUE,

parallel.sz = 4)

然而这个时候出现报错：

Error in GSVA::gsva(expr, signatures, method = "ssgsea", ssgsea.norm = FALSE, : Calling gsva(expr=., gset.idx.list=., method=., ...) is defunct; use a method-specific parameter object (see '?gsva').

奇怪，怎么GSVA报错？

这时去了解xCell运行原理，发现它其实是使用ssGSEA计算样本在每个细胞类型上的富集得分。（真的是羡慕嫉妒恨啊，就这么简单的一个包发布不到十年就好几千的引用了）

此时我紧跟一个心跳暂停，该不会是xCell的作者自己没有更新吧！！！由于GSVA在1.34版本更新了ssGSEA的运行方法，导致很多旧代码都无法运行报错。该不会xCell没有因此更新所以会报错吧？

我赶紧去github上查看了xCell的作者的原始代码。哎？这不是写得很清楚嘛，根据GSVA的不同版本执行不同命令，作者还是蛮人间清醒的。我的心放回去了一大半，还好还好了，那xCell应该是没有问题的。我又检查了一下服务器的GSVA 的R包版本，发现符合>=1.50.0。

那就奇怪了，问题又可能出现在哪里？

我接下来首先怀疑的就是服务器的xCell版本没更新。于是我重新下载了xCell。

> devtools::install_github('dviraran/xCell')

> library(xCell)

令人抓狂，依旧是一模一样的GSVA报错。现在貌似走入了一个死胡同：GSVA是新版的，xCell也根据GSVA 版本进行了调整没有问题，我甚至重新下载了xCell，但是为什么看上去xCell依旧无法运行新版GSVA ？

我命若游丝，又回到xCell的GitHub网站上寻找线索。发现Release的最新版是2020年发布的，但根据GSVA调整代码是发生在6个月前，但xCell并没有因为6个月前的调整发布1.4 version。

（此部分纯属个人臆测）突然，我灵光乍现。该不会正是因为官方没有更新R包的版本导致服务器管理人员没有办法更新到最新版吧？但是我明明从GitHub重新下载了最新版。

那答案只有一个，我下载的最新版xCell没有用上！！！ 一看，我加载的xCell果然在服务器公共路径上，而我自己的个人路径的文件夹存在另一个我刚刚下载的xCell。

> find.package("xCell")

[1] "/refdir/Rlib/xCell"

ls /home/data/t******/R/x86_64-pc-linux-gnu-library/4.4

我醍醐灌顶，修改了R包加载路径，想直接调用我自己文件夹里的R包。

> .libPaths("/home/data/t******/R/x86_64-pc-linux-gnu-library/4.4")

然而，怎料命途多舛，这次直接告诉我没有GSVA这个R包，无法加载xCell。

我冷静了一下，问题不大问题不大，我重新下一个GSVA就行了。

> library(xCell)

Error: package or namespace load failed for ‘xCell’ in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]): there is no package called ‘GSVA’

然而，GSVA它下不下来啊！

我又冷静了一下，问题不大问题不大，我从GitHub官网下载GSVA的压缩包，导入我的文件及再用devtools::install_local手动安装就好了。然而，我没有下载安装devtools啊！！这是在套娃吗！

我又又冷静了一下，问题不大问题不大，我仔细回顾了一下整个过程，突然意识到我之前用代码下载的R包（xCell）都储存在我自己的文件路径下，而我现在只是需要在我的文件路径下多安装一个GSVA而已嘛。那我其实可以来个借鸡下蛋嘛！！！

我立刻把调用R包的路径改回可调用服务器上的公共R包。用服务器上的devtools给自己安装了新的GSVA R包。检查确认我的文件夹里确实安装好了新的GSVA包！

> .libPaths(c("/home/data/t******/R/x86_64-pc-linux-gnu-library/4.4",

"/refdir/Rlib",

"/usr/local/lib/R/library"))

> library(devtools)

> devtools::install_local(“/home/data/t******/R/x86_64-pc-linux-gnu-library/4.4/GSVA-devel.zip “)

于是我再次将R包调用路径改到自己的文件夹里。

开心！这回我重新运行xCellAnalysis之后就没有任何报错啦！

> .libPaths("/home/data/t******/R/x86_64-pc-linux-gnu-library/4.4")

> library(xCell)

> xCell_results <- xCellAnalysis(TPM_exp,

rnaseq = TRUE,

parallel.sz = 4)

其实我后面反思，发现自己犯了个大错误。一般来说.libPaths后面的路径是有先后顺序的，我的习惯就是按照服务器的官方指导，把自己的文件夹放在路径的第一顺位。那为何上述find.package("xCell")始终显示在公共R包路径？经过我重新实践，我发现可能是因为当时忘记重新library了……如果当时记得重新library，我可能不用因为报错说没有GSVA而辛苦安装别的R包。

哎，所以解决这个bug其实很简单。

.libPaths中确保第一路径是自己的文件夹（用来调用最新的xCell），第二路径是公共R包文件夹（方便xCell使用GSVA） →

重新下载最新的xCell →

重新library(xCell) →

检查此时的xCell位置，确认是你刚刚下载的最新版 →

正常运行xCellAnalysis。

总之作为生信入门选手，其实上述很多流程存在大量新手的臆测和胡乱摸索，绕了一大圈弯路，也许大佬们会有更加简单直接的方法去解决问题。所以此篇笔记的目的肯定不是教大家怎么跑xCell等（我都还只是个一知半解的菜鸡）。只是在此总结几点私以为的关键要义：

1. 寻找报错的底层逻辑。遇到今天这样的报错，其实已经很幸运了，毕竟它讲得很清楚是GSVA无法运行导致的。那我们其实就要反过头去找为什么是GSVA？在这个R包的原代码里是怎么运行GSVA的？另外就是平时可以多关注一下类似GSVA这样重要的R包有什么更新点，会造成什么后果。我之前就是跟着网上的教程跑ssGSEA，无论如何都报错，这才去官网上查看发现GSVA有重要的更新。也正因如此，我一看到xCell也是无法运行ssGSEA之后才会很快冷静下来去翻xCell的原代码。
2. 注意R包的版本。很多时候都是R包套着R包，所以有时看似更新了一个R包，有可能跟它相关的其它R包会无法运行。这其实是个很容易被忽视的小细节，记得课上老师也说过这个问题。
3. 使用服务器的时候，需要关注R包路径。说到底，今天的bug其实就是R包更新问题以及R包路径问题。作为一个新手，平时图便利都直接调用服务器的R包，偶尔自己install一个R包，后续library也没出现过问题。这次机缘巧合就让我发现了如果.libPaths涉及到的多个路径都有同一个名称的R包时，调用顺序就可能成为一个小隐患，导致我走了一大圈弯路。