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

Hervé Pagès hp@ge@ @ending from fredhutch@org
Fri Oct 12 19:25:18 CEST 2018


I'm not too familiar with Rsamtools::pileup() but I know it does
handle indels. I also remember that last time I tried it was very
fast, very flexible, and has a very extensive man page.

H.

On 10/12/2018 09:09 AM, Tim Triche, Jr. wrote:
> 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 
> <mailto: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
>     <mailto: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 <mailto: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 <mailto: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 <mailto: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



More information about the Bioc-devel mailing list