Re: [Bioc-devel] class name collision in cache: igvR and Gviz

Hi Michael, Thank you for this work and the explanation. It’s good to know that my problem will feed back into improvements in the methods package. I opted for a simpler workaround, for now, renaming my abstract class to avoid the collision. - Paul > On May 8, 2018, at 8:25 AM, Michael

Re: [Bioc-devel] rsvg on mac

    Now that this past bioc release is done, and R 3.5 is stable, would it be possible to install the "rsvg" package on your build machines? Thanks. Kevin On 02/19/2018 02:01 PM, Alexey Sergushichev wrote: > Valerie, thanks. Will try to ask there. > > However, after looking through the

Re: [Bioc-devel] BioC 2018 poster / talk / scholarship / workshop application deadline May 17

The scholarships support up to $500 travel. The scholarship also covers accommodation and registration. A letter inviting you to the conference will be sent separately. Martin On 05/09/2018 01:13 AM, Pijush Das wrote: Dear Martin Morgan, Thank you Morgan for informing me to join your 

[Bioc-devel] Initial list of deprecated packages Bioc 3.8

The Bioconductor Team is continuing to identify packages that will be deprecated in the next release to allow for the Bioconductor community to respond accordingly. The list will be updated monthly. We are identifying the initial list for deprecation in release bioc 3.8. The following

Re: [Bioc-devel] rsvg on mac

Kevin, I feel like we're not on the same page. We've had this discussion and both Herve and I tried to explain the situation: https://stat.ethz.ch/pipermail/bioc-devel/2018-February/012812.html We do not build CRAN packages from source on the Windows and Mac build machines. If a CRAN binary

Re: [Bioc-devel] BiocInstaller: next generation

On 05/09/2018 07:05 PM, Aaron Lun wrote: This all sounds pretty reasonable to me. The ability to choose the version in install() is nice, especially if we can easily flip between versions in different install locations. I presume that version="release" will be the default? I actually have

Re: [Bioc-devel] BiocInstaller: next generation

On 05/09/2018 06:39 PM, Ryan Thompson wrote: Hi Martin, Is the intent that the BiocManager package should never be loaded via library, but functions in the package should always be called as BiocManager::FUN()? If not, I would consider prefixing the functions with "bioc". I would rather

Re: [Bioc-devel] BiocInstaller: next generation

Hi Martin, Is the intent that the BiocManager package should never be loaded via library, but functions in the package should always be called as BiocManager::FUN()? If not, I would consider prefixing the functions with "bioc". Also, I assume that once this BiocManager package is on CRAN, the

[Bioc-devel] BiocInstaller: next generation

Developers -- A preliminary heads-up and request for comments. Almost since project inception, we've used the commands source("https://bioconductor.org/biocLite.R;) biocLite(pkgs) to install packages. This poses security risks (e.g., typos in the url) and deviates from standard R package

Re: [Bioc-devel] BiocInstaller: next generation

This all sounds pretty reasonable to me. The ability to choose the version in install() is nice, especially if we can easily flip between versions in different install locations. I presume that version="release" will be the default? As for the names - BiocManager seems the most sober of the lot.

Re: [Bioc-devel] BiocInstaller: next generation

Hi Henrik, On Thu, May 10, 2018 at 1:21 AM, Henrik Bengtsson < henrik.bengts...@gmail.com> wrote: > > > May I suggest the package name: > > * Bioconductor > > The potential downside would be possible confusions between the version of > this package versus the actual Bioconductor repository.

Re: [Bioc-devel] BiocInstaller: next generation

On Thu, May 10, 2018, 00:29 Martin Morgan wrote: > Developers -- > > A preliminary heads-up and request for comments. > > Almost since project inception, we've used the commands > >source("https://bioconductor.org/biocLite.R;) >biocLite(pkgs) > > to install