Move differential expression analysis to separate package

[grst]

Description of feature

After factoring out the differential expression visualizations into deres, I've been thinking if it would also make sense to make a separate package for the differential expression testing altogether.

It's useful in many contexts (e.g. differential spatial analysis) as we've seen during the hackathon and I would like to have that available to the scverse ecosystem without the hefty dependency tree pertpy brings with it.

The new package (e.g. demodels) could then become a dependency of pertpy and the corresponding class definitions could be re-rexported in the pertpy API such that there are no user-facing changes.

LMK what you think @Zethson.

[maltekuehl]

I support this idea which seems to align with how I personally would use pertpy, which would largely just be for differential expression. Typical pertpy applications as initially conceptualized might also not directly benefit from the implementation of additional statistical testing features (e.g., more test statistics, flexibilizing existing APIs to offer a more modular composability, etc.) but other packages might and in my opinion it could make sense to unlink the development processes and feature sets. If this were to be of interest, I would be happy to help with the development of the outsourced package.

[Zethson]

Totally fine with me as long as there are no user facing changes (for now). Making pertpys dependencies leaner is still an achievable goal of mine but I am overloaded for the next few months.

+1!

[Zethson]

I'm investing a lot of tokens into pertpy now to catch up on many old issues. I wonder whether it'd be fine to instead make Jax optional in pertpy and then keep everything in pertpy. Honestly, I don't think that anyone has the will or bandwidth to maintain yet another package. Pertpy isn't that fat anymore and without Jax, it should be pretty lean actually. I can ensure that things keep running.

Thoughts?

[grst]

Is there anything you'd want to change in pertpy wrt to DE methods? Overall I don't think there's a huge difference in maintainance burden if the methods live in pertpy or in another package. If the dependencies are lean enough, I also don't mind them being implemented in pertpy.

[Zethson]

I'd probably ensure that all of your issues here are closed & we're adding a few more plots.
Still no strong opinion.