> I can confirm this. Would it then be appropriate for scMerge to add a > (>= 1.7.3) after its Imports: entry for SingleCellExperiment?
I don't think this is really necessary; 1.7.3 will propagate soon enough, at which point people just need to stay updated. > Basically, before we commit changes to a class, it should not be too hard > to assess the downstream effects and notify relevant developers. Well, it *should* have been a transparent change (even for serialized objects), it's just that there was a bug. This is not surprising - who knows how many times S4Vectors has broken one of my packages - and my attitude is to not do anything unless the fail persists in >=3 build cycles. -A On Fri, Aug 2, 2019 at 9:19 AM Pages, Herve <hpa...@fredhutch.org> wrote: > > This is a really important point. > > Finding and updating serialized S4 instances that are lying around > as they evolve can be painful and very time-consuming. > > We should definitely avoid storing serialized S4 objects on the Hub. > I don't know about ExperimentHub but at least for AnnotationHub I > believe that we've been careful to avoid storing serialized S4 > instances there. The S4 objects that land on the user space are > generally assembled on the user side from raw files downloaded from > the Hub. > > H. > > > On 8/2/19 02:58, Vincent Carey wrote: > > On Thu, Aug 1, 2019 at 10:36 PM Aaron Lun < > > infinite.monkeys.with.keyboa...@gmail.com> wrote: > > > >> One possibility is that this is due to a regression in > >> SingleCellExperiment, caused by the altexp updates and other > >> refactoring. This should be fixed in 1.7.3, you can check this for > >> yourself by installing drisso/SingleCellExperiment off GitHub. > >> > > > > I can confirm this. Would it then be appropriate for scMerge to add a > > (>= 1.7.3) after its Imports: entry for SingleCellExperiment? > > > > > >> > >> The other moral of the story is to not use serialized high-level > >> objects. Serializing basic objects is fine, but the higher up you go, > >> the more fragile your code becomes to refactoring. See, for example, the > >> scRNAseq data package for how to deliver a SingleCellExperiment to an R > >> session without relying on serialized SingleCellExperiments. > >> > > > > I have run into this issue also. It is convenient to serialize a high-level > > object. Breaking it down to its constituents, and assembling it, is > > a lot more effort. scRNAseq:::.create_sce shows how to reassemble for > > SingleCellExperiments. > > > > Is this a principle we want to adopt? Avoid serializing "non-basic" > > objects? > > updateObject methods should help centralize the effort to managing object > > designs and their implementation. > > > > It seems it would be wise to implement this principle for any resource that > > might be used by both release and devel ... even in devel we may see more > > breaking changes propagating as S4 classes evolve, if objects are > > serialized. > > Adding validObject tests in tests/ could reduce surprises. Helping class > > maintainers know what packages have serialized fragile objects might be a > > task for BiocPkgTools -- but a nontrivial one. Maybe a BiocDevTools package > > would be more appropriate. And checking hub elements seems relevant too. > > > > Basically, before we commit changes to a class, it should not be too hard > > to assess the downstream effects and notify relevant developers. The > > alternative > > of banning serialized S4 objects seems too harsh and possibly ambiguous. > > On the other hand it may be necessary to ban serialized S4 in the *Hubs? > > > > > > > > > >> > >> -A > >> > >> On 8/1/19 7:14 PM, Kevin Wang wrote: > >>> Hi all, > >>> > >>> I am getting a strange build error message for scMerge ( > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_scMerge_malbec1-2Dbuildsrc.html&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=L4f9oTVSpwscJMPgdi1rNvsOuwzZZcI4el6nnCGyeIg&e= > >> ) > >> that reads > >>> > >>> + "C stack usage is too close to the limit” on Linux and Mac and > >>> + "evaluation nested too deeply: infinite recursion” on Windows, when > >> building the vignette file “scMerge.Rmd”. > >>> > >>> However, when I was building the Rmd locally and also on Travis + > >> pkgdown under BioC3.10 ( > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_SydneyBioX_scMerge_builds_566753523&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=OfWVIoa8JmqXoQPtzL6NMUEnMr3Olucnl1QXb9BdhU4&e= > >> ), I had no > >> errors. This file has not been edited for 2 months ( > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SydneyBioX_scMerge_blob_master_vignettes_scMerge.Rmd&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=5hKxs2682qAud9bqp-7yWC6UdgioYcy3IA7xDu5tmSY&e= > >> ). > >>> > >>> Any help would be appreciated. > >>> > >>> Thank you > >>> Best Wishes > >>> Kevin > >>> > >>> PhD Candidate > >>> Faculty of Science, School of Mathematics and Statistics > >>> THE UNIVERSITY OF SYDNEY > >>> > >>> [[alternative HTML version deleted]] > >>> > >>> _______________________________________________ > >>> Bioc-devel@r-project.org mailing list > >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=_iNo7wAh9O7hkrGcVDo6HLz33EINR1_3n-3VQh0wcLk&e= > >>> > >> > >> _______________________________________________ > >> Bioc-devel@r-project.org mailing list > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=_iNo7wAh9O7hkrGcVDo6HLz33EINR1_3n-3VQh0wcLk&e= > >> > > > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fredhutch.org > Phone: (206) 667-5791 > Fax: (206) 667-1319 _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
