You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: