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

[Morgan, Martin]

There is .BBSoptions, which can be placed in the root of your package, 
but this is insidious, as evidenced by your own use case -- gmapR 
doesn't support windows, so your package doesn't support windows, so any 
package that Depends: or Imports: your package doesn't support windows, 
so actually 1/2 of our users can't reliably use packages we provide.

I would argue for a much more carefully defined package with specific, 
cross-platform functionality. This will be easier to maintain AND more 
useful. Generally, I think we are really seeing an explosion of 
dependencies, and that this is very bad for long-term utility of 
contributed packages -- the maintainer will either spend all their time 
responding to changes in dozens of dependent packages rather than 
innovating in new areas, or will give up and leave the users with 
software that no longer works.

Martin

On 10/10/18 10: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?
> 
> http://bioconductor.org/spb_reports/MTseekerData_buildreport_20181010103212.html
> 
> 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://stat.ethz.ch/mailman/listinfo/bioc-devel
>