[Bioc-devel] how can I declare that a package doesn't/can't fully support Windows

[Tim Triche, Jr.]

can it handle indels reasonably well?  It might be a reasonable substitute,
especially if it can spit out a VRanges somehow

--t


On Thu, Oct 11, 2018 at 10:14 AM Hervé Pagès <hpages using fredhutch.org> wrote:

> Sounds good.
>
> I should also mention that Rsamtools has pileup() that is available
> on all platforms. Don't know how easy it would be to use to achieve
> the kind of variant calling you're doing in MTseeker though...
>
> Cheers,
> H.
>
> On 10/11/2018 04:35 AM, Tim Triche, Jr. wrote:
> > This makes sense. Windows users won’t be easily able to call variants
> across thousands of samples but at least the plotting, impact prediction,
> etc will work fine for them.
> >
> > I will need to define things such that the variant calling is optional,
> which is not too absurd — I’ll add loading of MVRanges/MVRangesList objects
> from VCFs and move gmapR to suggests.
> >
> > Personally I use the variant calling functionality regularly, but I have
> my doubts as to whether someone on Windows would even have enough RAM to
> call variants across 2000+ samples in a shot, so this is a good
> compromise.  Everything else is, I believe, platform agnostic. This should
> work.
> >
> > --t
> >
> >> On Oct 11, 2018, at 1:41 AM, Hervé Pagès <hpages using fredhutch.org> wrote:
> >>
> >> And of course: the whole trick I described below only makes sense
> >> if MTseeker doesn't rely on gmapR for its core functionality, that
> >> is, if not having gmapR installed still allows the user to accomplish
> >> something meaningful with MTseeker.
> >>
> >> Otherwise the trick below will make MTseeker available on Windows
> >> but Windows users won't be able to accomplish anything meaningful
> >> with it. In that case, marking the package as unsupported on Windows
> >> would be preferable.
> >>
> >> Hope this makes sense,
> >>
> >> H.
> >>
> >>> On 10/10/2018 10:26 PM, Hervé Pagès wrote:
> >>> Hi Tim,
> >>> No platform-specific dontrun capabilities AFAIK but you can use
> >>> something like:
> >>>    if (requireNamespace("gmapR", quietly=TRUE)) {
> >>>        ...
> >>>        ...
> >>>    }
> >>> in your man pages.
> >>> You would also need to move gmapR from Imports to Suggests.
> >>> Then make sure that MTseeker passes 'R CMD check' **without**
> >>> the gmapR package being installed. You'll need to define and set
> >>> environment variable _R_CHECK_FORCE_SUGGESTS_ to 0 for this.
> >>> Do it with:
> >>>    export _R_CHECK_FORCE_SUGGESTS_=0
> >>> on Linux or Mac, or with:
> >>>    set _R_CHECK_FORCE_SUGGESTS_=0
> >>> on Windows.
> >>> Once MTseeker is accepted, we'll add a .BBSoptions file with special
> >>> directive:
> >>>    CHECKprepend.win: set _R_CHECK_FORCE_SUGGESTS_=0&&
> >>> This will have the effect to set the environment variable on the
> >>> Windows build machines before running 'R CMD check' there.
> >>> So MTseeker will be supported and available on all platforms.
> >>> For MTseekerData: the package doesn't seem to make any use of gmapR
> >>> so you can probably remove gmapR from its Suggests field.
> >>> Hope this helps,
> >>> H.
> >>>> On 10/10/2018 07:46 AM, Tim Triche, Jr. wrote:
> >>>> it looks like gmapR does not support Windows, and as a result, my
> MTseeker
> >>>> package cannot build on tokay1, so the Data package which requires it
> also
> >>>> cannot build on tokay1.  Are there platform-specific dontrun
> capabilities?
> >>>>
> >>>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_spb-5Freports_MTseekerData-5Fbuildreport-5F20181010103212.html&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=x8fxgyra6DmetOzKCh1Zm1X25BwPM7TDr8UUNYwgV18&s=QNKSsmQnfEAQOTI0r8dDuW_d01XzL_cL1cb5QIElLxw&e=
> >>>>
> >>>> Short of somehow forcing gmapR to build on Windows, which I believe is
> >>>> beyond my control, is there a way to declare that parts of the
> MTseeker
> >>>> package are unsupported/unsupportable on Windows?
> >>>>
> >>>> I suppose I could cleave off the variant-recalling portions but that
> seems
> >>>> a little ridiculous. The original goal was to take the non-NuMT reads
> from
> >>>> a given alignment, realign (only) those to rCRS/RSRS, and call against
> >>>> that, for better mitochondrial haplogroup inference. We're still
> working
> >>>> towards the full version, but even just calling variants against rCRS
> with
> >>>> indels is hugely useful, and the ability to screen out
> haplogroup-specific
> >>>> variants while retaining indels, SNVs, etc. turns out to be VERY
> handy.
> >>>> More generally, there isn't any equivalent (AFAIK) in BioC, at all.
> >>>>
> >>>> --t
> >>>>
> >>>>      [[alternative HTML version deleted]]
> >>>>
> >>>> _______________________________________________
> >>>> Bioc-devel using r-project.org mailing list
> >>>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=x8fxgyra6DmetOzKCh1Zm1X25BwPM7TDr8UUNYwgV18&s=rzPUqLBge6xE1TymeYxIxJxkiiOHefbSgzPOLYEhvrM&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: hpages using fredhutch.org
> >> Phone:  (206) 667-5791
> >> Fax:    (206) 667-1319
>
> --
> 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: hpages using fredhutch.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319
>

	[[alternative HTML version deleted]]