Re: [Bioc-devel] Advice (was Re: CRAN package with Bioconductor dependencies)

- Original Message - > From: "Kevin Coombes" > To: "Laurent Gatto" , "Henrik Bengtsson" > > Cc: "bioc-devel" > Sent: Wednesday, March 4, 2015 2:21:37 PM > Subject: [Bioc-devel] Advice (was Re: CRAN package with Bioconductor > dependencies) > > HI, > > I'm following this discussion

Re: [Bioc-devel] Advice (was Re: CRAN package with Bioconductor dependencies)

On Wed, Mar 4, 2015 at 5:21 PM, Kevin Coombes wrote: > HI, > > I'm following this discussion with interest, for the following reason. > There are more than a dozen packages that I have written and still > maintain. Most of them were started while I was at M.D. Anderson , They > were served from

Re: [Bioc-devel] CRAN package with Bioconductor dependencies

Hi Gordon, On 03/04/2015 02:12 PM, Gordon Brown wrote: Hi, Hi, Bioc-devel folks, Is there an accepted way to migrate a package from CRAN to BioC? CRAN's policy says, "The package�s license must give the right for CRAN to distribute the package in perpetuity."... Is it enough to request tha

Re: [Bioc-devel] New(ish!) Seattle Bioconductor team member

On Wed, Mar 4, 2015 at 2:29 PM, Michael Lawrence wrote: > Welcome. > > For those who don't know, Jim is also the author of the neat "lintr" > package, which checks your R code as you type, across multiple editors. > > https://github.com/jimhester/lintr Not to mention https://github.com/jimhester/

Re: [Bioc-devel] CRAN package with Bioconductor dependencies

On Wed, Mar 4, 2015 at 1:27 PM, Laurent Gatto wrote: > > On 3 March 2015 06:07, Henrik Bengtsson wrote: > >> Not that long ago DESCRIPTION field 'Additional_repositories' was >> introduced which the purpose of providing references to non-mainstream >> package repositories, e.g. R-Forge. Interest

Re: [Bioc-devel] New(ish!) Seattle Bioconductor team member

Welcome. For those who don't know, Jim is also the author of the neat "lintr" package, which checks your R code as you type, across multiple editors. https://github.com/jimhester/lintr Michael On Wed, Mar 4, 2015 at 2:20 PM, Martin Morgan wrote: > Let me take this belated opportunity to intro

[Bioc-devel] Advice (was Re: CRAN package with Bioconductor dependencies)

HI, I'm following this discussion with interest, for the following reason. There are more than a dozen packages that I have written and still maintain. Most of them were started while I was at M.D. Anderson , They were served from a highly non-mainstream repository hosted there, with the c

[Bioc-devel] New(ish!) Seattle Bioconductor team member

Let me take this belated opportunity to introduce Jim Hester to the Bioconductor developer community. Jim is working in the short term on SummarizedExperiment, including the refactoring efforts he introduced yesterday as well as coercion methods to and from ExpressionSet (an initial version f

Re: [Bioc-devel] CRAN package with Bioconductor dependencies

Hi, > > Hi, Bioc-devel folks, > > > > Is there an accepted way to migrate a package from CRAN to BioC? > > CRAN's policy says, "The package�s license must give the right for > > CRAN to distribute the package in perpetuity."... > > > > Is it enough to request that CRAN archive the package, then s

Re: [Bioc-devel] CRAN package with Bioconductor dependencies

On 3 March 2015 06:07, Henrik Bengtsson wrote: > Not that long ago DESCRIPTION field 'Additional_repositories' was > introduced which the purpose of providing references to non-mainstream > package repositories, e.g. R-Forge. Interestingly, by "mainstream" > they mean CRAN and Bioconductor. Th

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

On 03/04/2015 10:03 AM, Peter Haverty wrote: Michael has a good point. The complexity of the BioC universe of classes hurts our ability to attract new users. More classes would be a minus there ... but a small set of common, explicit APIs would simplify things. Rectangular things implement the ma

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

My response was meant to address this: 1) fixed-dimension, fixed sample set is a solved problem, and SE is that solution. 2) multi-assay, "holes" across samples remains an ugly thorny problem, maybe needs a new API So why not keep SE as stable as possible, and dump all the explosive changes into

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

some of the goals behind this discussion are IMO similar to the ones for biocMultiAssay: https://github.com/vjcitn/biocMultiAssay maybe Vince can confirm. robert. On 03/04/2015 05:16 PM, Tim Triche, Jr. wrote: Oh, I don't disagree. Perhaps the two problems can be addressed simultaneously by

Re: [Bioc-devel] CRAN package with Bioconductor dependencies

- Original Message - > From: "Gordon Brown" > To: bioc-devel@r-project.org > Sent: Wednesday, March 4, 2015 3:30:35 AM > Subject: Re: [Bioc-devel] CRAN package with Bioconductor dependencies > > Hi, Bioc-devel folks, > > Is there an accepted way to migrate a package from CRAN to BioC?

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

Clarification: the complexity of the full BioC class universe, not the SE/eSet part. GenomicRanges, GRanges, GRangesList, RangesView, RangesViewsList, ... I think all of that intimidates new people. Maybe that's not generally the case. Sorry, I've taken this thread way off topic. I'll stop now.

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

What complexity? The Nature Methods paper laid it out: for most people, most of the time, use an SE. That way, the organization of metadata and covariates is enforced for you, like an ExpressionSet (another winning data structure) but without its baggage. Maybe the "Summarized" in the name isn't

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

Michael has a good point. The complexity of the BioC universe of classes hurts our ability to attract new users. More classes would be a minus there ... but a small set of common, explicit APIs would simplify things. Rectangular things implement the matrix Interface. :-) Deprecating old stuff, lik

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

I think we need to make sure that there are enough benefits of something like GRangesFrame before we introduce yet another complicated and overlapping data structure into the framework. Prior to summarization, the ranges seem primary, after summarization, it may often make sense for them to be seco

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

so I'm told: https://github.com/vjcitn/biocMultiAssay/blob/master/R/triche.R Statistics is the grammar of science. Karl Pearson On Wed, Mar 4, 2015 at 9:01 AM, Robert Castelo wrote: > some of the goals behind this discussion are IMO simil

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

On Wed, Mar 4, 2015 at 12:01 PM, Robert Castelo wrote: > some of the goals behind this discussion are IMO similar to the ones for > biocMultiAssay: > > https://github.com/vjcitn/biocMultiAssay > > maybe Vince can confirm. > It is true that there are connections between the concerns But the way

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

Oh, I don't disagree. Perhaps the two problems can be addressed simultaneously by 1) deciding on what contracts a multi-assay container can/would demand to be useful 2) calling it something besides SummarizedExperiment, say, ExperimentCollection Then the SE API could stay the same as it is (whic

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

I am a bit concerned about any major alterations to the SummarizedExperiment API. We have two papers and plenty of working code that use it in meaningful ways. Effort required to keep new formulations back-compatible as well as bug-free has to be weighed seriously. I agree that the name is not id

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

May I advocate for 'IndexedDataFrame' or 'IndexedFrame'? 'rowIndices' can return whatever makes sense (GRanges, or other data structures -thinking taxonomy for metagenomics for example-). GRangesFrame can inherit from this. On Wed, Mar 4, 2015 at 3:28 AM, Hervé Pagès wrote: > GRangesFrame is an

Re: [Bioc-devel] CRAN package with Bioconductor dependencies

Hi, Bioc-devel folks, Is there an accepted way to migrate a package from CRAN to BioC? CRAN's policy says, "The package�s license must give the right for CRAN to distribute the package in perpetuity."... Is it enough to request that CRAN archive the package, then submit it as a new package to

Re: [Bioc-devel] Changes to the SummarizedExperiment Class

GRangesFrame is an interesting idea and I gave it some thoughts. There is this nice symmetry between GRanges and GRangesFrame: - GRanges = a naked GRanges + a DataFrame accessible via mcols() - GRangesFrame = a DataFrame + a naked GRanges accessible via some accessor (e.g. rowR