[Bioc-devel] Help with creating first Bioconductor package
----- 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