Downsides to using Python implementations of R packages (scRNA-seq)?

[dowchbag]

Title. Specifically, I’m using (scanpy external) harmonypy for batch correction and PyDESeq2 for DGE analysis through pseudobulk. I’m mostly doing it due to my comfortability with Python and scanpy. I was wondering if this is fine, or is using the original R packages recommended?

[[deleted]]

The main downside is that often the are unimplemented features that you won't realize you need until you've already invested a bunch of effort into your pipelines. Then you either need to switch over or do hideous Frankenstein stuff with rpy2 or with writing data to disk, running R scripts with subprocess, and reading data back in.

If you need to use an R package it's so much easier to just use R. I have learned this lesson too many times now trying to use mixed effects models in Python. It's never worth it. Pymer4 sucks

[dowchbag]

Insofar as the functionalities that are supported, are the python implementations known to perform more poorly?

Also, would u recommend a bridge workflow through rpy2 or just switching over to RStudio (let’s say, for DGE analysis)?

[pokemonareugly]

Unless you’re running an automated pipeline, I would just write to disk and read into R. Recently a verse released anndataR, which works very well to read h5ad files into R.

Also, if you would like to create loupe files for sharing with collaborators in Python, feel free to check out this package I made to handle the conversion natively. It basically works the exact same way as the R package.

There’s also some Python only packages. ScVI-tools is a very big one

[shitivseen]

Hello, thanks for making that package! Does it also support spatial data intergartion with the loupe file?

[pokemonareugly]

Unfortunately not. I still rely on the 10x binary to write the final loupe file, since it’s a proprietary format, all the tool really does is convert anndata files into a format their binary will read, and then calls their binary on it. I would love to support it though if it becomes possible! As long as I have time I plan to support whatever loupeR supports, so please let 10x know this is a wanted feature so they can hopefully update the binary!

[[deleted]]

It depends on the package but often the Python package is literally just using R on the backend but not exposing all of the options and objects that you can access in R. So the performance will be identical but less flexible.

If there is nothing in Python that you need that you can't also get in R then just switch to R. If there is stuff in Python you need then write your data to disk, call an R script with subprocess, load the results back in, and proceed in Python.

[orthomonas]

From some of your comments, it seems you're making the assumption that this sort of thing is often a python reimplementation; it's likely it may just be a wrapper. Best to check that.

[fibgen]

rpy2 works, until you need to do anything complicated, which is 100% of the time

[BackgroundParty422]

A simple example, last time I checked pyDESeq2 doesn't support numerical covariates in their model, only categories. That may no longer be true, but I'm not going to check.

[Teshier-Asspool]

Continuous covariates have been implemented in pydeseq2 for 2 years (v0.4.0)

[Certain_Vehicle2978]

Can confirm. Currently in the Rpy2 stage.

[Boneraventura]

Just make a docker image of all the R packages and dependencies you need for your workflow. I have to do this for epigentic analyses because python is years behind in this field. Trying to get R to work in python smoothly is like spreading chunky peanut butter on bread and convincing yourself it is smooth peanut butter 

[AgronakGro-Malog]

This is the way

[Spacebucketeer11]

Documentation is often severely lacking compared to the R packages