Hi Tim, As Michael said, the usual case is the data package 'Suggests' the software and the software 'Depends' or 'Imports' the data but this dependency could be reversed.
When submitting a combo of packages to the SPB for review, the package that 'Suggests' is submitted first followed by the package that 'Depends'. More on that here: https://github.com/Bioconductor/Contributions#submitting-related-packages One additional step taken to transition the packages to the build system after approval is to add a .BBSoptions file in the package that 'Suggests'. In this example, the .BBSoptions would be in the data package and have this one line: ForceInstall: TRUE Valerie On 10/6/18 11:06 AM, Michael Lawrence wrote: I think you're doing the right thing, suggesting the data package from the software package. This might require some manual intervention on the build system side to ensure that the software package is installed before passing full check, so that the data package can be installed/checked and finally the software package checked. I guess a note about this could be added to the page at the cited URL. Michael On Sat, Oct 6, 2018 at 10:42 AM Tim Triche, Jr. <tim.tri...@gmail.com><mailto:tim.tri...@gmail.com> wrote: Last night I submitted MTseeker and its companion package MTseekerData, both festooned with examples that run smoothly and pass BiocCheck. HOWEVER! Breaking up the data into a Data package inadvertently seems to have created a circular dependency between the Software and Data packages. I haven't had to deal with this in the past, and mostly sidestepped it by skipping a Depends: entry in Data. (cf. https://support.bioconductor.org/p/113711 , which I will update with answers from here to try and avoid having other people with the same problem bug youse plural) The issue seems to be that, since the MTseeker-defined MVRanges and MAlignments classes (which, as you might imagine, subclass the VRanges and GAlignments classes) hold the data stored in MTseekerData, the examples in MTseekerData call the `show` method (and others) on the objects and this create issues. The most bizarre of these complained at installation about (sp?) .lazyLoadCacheManager() (I'm having trouble reproducing this exact error but it was memorable). Does this ring a bell for anyone? Is there an elegant workaround? I can't imagine I'm the first person to have this issue. I know there are also various automagic hooks in BioC to load a package upon discovering a data structure that belongs to it (and not before) -- should I be using attachNamespace() somehow to side-step this problem? (Eventually I do want to submit BAM files to ExperimentHub for an end-to-end example and unit tests, but the more pressing issue here was BiocCheck). Any feedback is much appreciated. It's kind of a drag when all the examples and vignettes pass and build, but only with a side-stepping of dependencies. That can't possibly be the correct solution, yet I'm at a loss to find documentation (which I'm sure exists somewhere) that explains how to avoid this (and/or implement the hooks). Thank you, --t [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
