self.current_fit_type doesn't seem to be used elsewhere, so the deseq2() fit_type argument doesn't have any effect

Good catch, forgot to set it to fit_type.

If we set a new fit_type in VST, then I think we should either set it back to the one provided at initialization, or make it clear that it will also change the fit type used in deseq2()

If I understand correctly, the user should be able, after he launches vst with its own fit_type, to launch deseq2 and expect the fit_type he provided at initialisation?

Is there a risk if deseq2 and vst have their own separate fit_type (lets say self.vst_fit_type and self.dea_fit_type) and since they both share all the other attributes filled during the fit, that vst will compute stuff that deseq2 will have access to it but is not supposed to?

In that case, should they not share any of the attributes (varm, obs, design_factors etc) ?

Sorry for the late answer @laudmt!

If I understand correctly, the user should be able, after he launches vst with its own fit_type, to launch deseq2 and expect the fit_type he provided at initialisation?

I think that this is indeed what should happen by default, i.e. if no other fit_type is provided when calling deseq2().

Is there a risk if deseq2 and vst have their own separate fit_type (lets say self.vst_fit_type and self.dea_fit_type) and since they both share all the other attributes filled during the fit, that vst will compute stuff that deseq2 will have access to it but is not supposed to?

In that case, should they not share any of the attributes (varm, obs, design_factors etc) ?

Currently, this is what happens. vst() and deseq2() populate the same fields (varm["genewise_dispersions"] and uns["trend_coeffs"] in particular), but they recompute and overwrite them every time (except in the case when we call vst(use_design=True) after calling deseq2() with the same fit type, in which case we can re-use the computation).

In principle, the only issue I see with this is if a user calls e.g. vst(use_design=False) after deseq2(). In that case, varm["genewise_dispersions"] will be overwritten, and if the user wants to perform some analysis of the gene-wise dispersions (e.g. if they call plot_dispersions()), then they will access the wrong values (not the ones used in the DEA).

Perhaps a cleaner thing to do would be to prefix any parameter stored by vst() with "vst_"? (varm["vst_genewise_dispersions"], uns["vst_trend_coeffs"], etc.). This would create some memory overhead but would prevent any confusion. What do you think?