[Bioc-devel] Help with creating first Bioconductor package

[Dan Tenenbaum]

----- Original Message -----
> From: "January Weiner" <january.weiner at gmail.com>
> Cc: "bioc-devel" <bioc-devel at r-project.org>
> Sent: Friday, November 14, 2014 1:11:32 PM
> Subject: Re: [Bioc-devel] Help with creating first Bioconductor package
> 
> Dear all,
> 
> thanks for your input, it was very helpful. I have some other
> specific
> questions, though:
> 
> Martin
> > You'll want to develop your package on Bioc- and R-devel, as this
> > is the environment in which your package will be introduced to
> > the Bioc community.
> 
> Specifically, I won't want to; I will have to. This is the last
> obstacle and I am aware of it. There is no way that I do my research
> on development version of R (not only for scientific reasons,
> unfortunately), so I need two versions running concurrently. There
> are
> means and ways to do it (I guess from the fact that it all runs on
> svn
> and that one can set up scripts setting environmental variables;
> there
> is no real guide on that, am I right?), but from my experience, for
> someone who is not a full time developer it will be horrible, and
> keeping it up to date -- without automata and apt-get -- will sooner
> or later lead to a disaster.
> 

No.

Keep R-release up to date with your OS's package manager. Build R-devel from source
and call either don't put it in your PATH and/or call its executable something else (Rdev?) instead of R.
You won't have to update it unless there are newer features of R-devel that break your package.



> Julian:
> > If you want to check it beforehand, have a look at
> > e.g. http://win-builder.r-project.org/.
> 
> I use it regularly to check my CRAN packages (pca3d, riverplot and
> tagcloud), but I assumed that it does not have org.Hs.eg.db and GO.db
> which I need for my vignette.
> 
> True, most likely there will not be any problems -- but I have had at
> least once troubles with a package that did not build correctly on
> Windows only (well, it did include C code).

As Martin mentioned, BioC has its own package builder available to you once you submit a package. It's absolutely fine if your package fails on one or more platforms when you submit it. Just look at the reports produced, fix the issue, and upload a new tarball. We don't find this annoying at all; on the contrary.

> 
> Tim Triche, Jr:
> > "S3 objects as far as the eye can see"
> 
> Is using S3 a problem? For simple things like to overload a few
> standard functions like plot and print? (Also, as a I user, I much
> prefer limma's EList than anything that was even lying next to an
> ExpressionSet; but then, I like Perl much more than Python).
> 
> Nathaniel Hayden:
> > Yihui's formatR (
> > http://cran.r-project.org/web/packages/formatR/index.html ) makes
> > formatting R files so simple and painless
> 
> That is precisely the package I had in mind when I said that it would
> be annoying -- I'd still need to switch (and worse, *remember to
> switch*) between the two formatting styles whenever I was to submit a
> package :-)


Don't change your formatting if you don't want to. As the BioCheck vignette says (and as the word CONSIDER should tip you off), doing so is optional. These things are a matter of taste. If you like to indent two spaces, that's fine. We find really long lines (> 80 characters) a bit annoying but the number of spaces you use is a matter of personal taste. It's good to be consistent with yourself though....so if adding code from a developer who likes to use 4 spaces, that might be a thing to fix.

Dan


> 
> Kind regards,
> 
> j.
> 
> --
> -------- January Weiner --------------------------------------
> http://logfc.wordpress.com
> 
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>