Thanks Kevin! That would have been my proposed option 3 if I had realised it would be that simple.
This will make my (and several other analysts I know's) lives a lot easier! Cheers, Kieran On 10 April 2014 16:11, Kevin Ushey <kevinus...@gmail.com> wrote: > Hi Kieran, > > I've kickstarted the process by sending a pull request here: > https://github.com/RGLab/flowCore/pull/21 > > Thanks, > Kevin > > > On Thu, Apr 10, 2014 at 3:48 PM, Kasper Daniel Hansen < > kasperdanielhan...@gmail.com> wrote: > >> My 2ct is that it is worthwhile to have a lean core package. It sounds >> like it would be trivial to separate gating into a new package, and - >> provided functions are not renamed - would be trivial for downstream >> packages to adapt to. >> >> Especially in situations where competing groups work on the same analysis >> domain, it is great if they can agree on basic data representation, and >> that chance is increased (IMO) if the core package does not include too >> much analysis tools. >> >> Best, >> Kasper >> >> >> On Thu, Apr 10, 2014 at 6:35 PM, Kevin Ushey <kevinus...@gmail.com>wrote: >> >>> Hi Kieran, Dan, >>> >>> I would suggest that you open an issue at >>> https://github.com/RGLab/flowCore/issues/new. >>> >>> Perhaps the easiest solution is to copy featureSignif from feature into >>> flowCore (giving adequate citation and such, respecting licenses...). It >>> looks like the function doesn't depend too much on other functionality in >>> the feature package, so this shouldn't be too much of a problem. >>> >>> Thanks, >>> Kevin >>> >>> >>> On Thu, Apr 10, 2014 at 3:15 PM, Kieran O'Neill <kone...@bccrc.ca> >>> wrote: >>> >>> > On 10 April 2014 14:26, Dan Tenenbaum <dtene...@fhcrc.org> wrote: >>> > >>> > > Hi Kieran, >>> > > >>> > > >>> > > ----- Original Message ----- >>> > > > From: "Kieran O'Neill" <kone...@bccrc.ca> >>> > > > To: bioc-devel@r-project.org >>> > > > Sent: Thursday, April 10, 2014 2:03:41 PM >>> > > > Subject: [Bioc-devel] Dependency on windowing systems in the >>> flowCore >>> > > package >>> > > > >>> > > > In Bioconductor, the core infrastructure for loading and >>> representing >>> > > > flow cytometry data is the flowCore package. It contains some very >>> > > > useful structures, most notably the flowFrame and flowSet classes, >>> as >>> > > > well as read.FCS, which loads the (somewhat complicated, binary) >>> FCS >>> > > > file format. >>> > > > >>> > > > However, at some stage flowCore gained functionality for performing >>> > > > automated gating, and a dependency on the feature package from >>> CRAN. >>> > > > Feature depends on the tcltk C++ libraries, which in turn depend on >>> > > > C++ libraries for a windowing system (X11 on *nix). This can make >>> > > > compiling flowCore a massive pain on a headless server or compute >>> > > > cluster. It can also be somewhat painful to more naive users on, >>> say, >>> > > > Ubuntu, who would have to install a number of development header >>> > > > packages. I believe this would also be a problem on OSX. >>> > > > >>> > > >>> > > There is a binary of flowCore for OS X. >>> > > >>> > > > I wrote about this issue on the list about a year ago, mostly as an >>> > > > aside. But I am now in the position of reviewing a new flow >>> cytometry >>> > > > package, where the author does not want to use flowCore to >>> represent >>> > > > flow cytometry data. Their reasoning is that their package is very >>> > > > basic, and they don't want to create complicated dependencies and >>> > > > installation issues for their end users. I'm at least halfway >>> > > > inclined >>> > > > to agree, but the guidelines do state that packages should "re-use >>> > > > existing S4 classes and generics where possible". >>> > > > >>> > > > And so I have a dilemma, which has two likely solutions: >>> > > > >>> > > > 1. The maintainers of flowCore change the package so it no longer >>> has >>> > > > Byzantine dependencies that include a windowing system. >>> > > > >>> > > I believe the flowCore maintainers are on this list and will >>> respond, but >>> > > they are the ones you really want to >>> > > address this question to. Next time you can CC them to make sure they >>> > > receive the message. >>> > > >>> > > >>> > Yes, I forwarded the email to Mike as well in case he didn't see it on >>> the >>> > list. I wanted it to be a more open discussion, though, since it >>> > potentially affects quite a lot of packages, and it does open up a few >>> > broader issues. >>> > >>> > >>> > > [the section below is my own personal opinion, not any official >>> policy] >>> > > >>> > > I don't know much about flowCore or how it uses X11, but I do think >>> that >>> > > web-based visualization has come quite a long way and might be worth >>> > > looking into as a more modern, platform neutral solution which does >>> not >>> > add >>> > > any difficult-to-build system dependencies. >>> > > >>> > > I saw an impressive presentation of the ggvis package lately ( >>> > > https://github.com/rstudio/ggvis). It is not yet on CRAN so we can't >>> > > accept its use in Bioconductor packages yet, but we can probably >>> expect >>> > it >>> > > to be added sometime during the upcoming BioC release cycle (would be >>> > good >>> > > to confirm that with its authors). >>> > > >>> > > Maybe the X11-dependent parts of flowCore could be ported to ggvis? >>> > > >>> > > [/end opinion] >>> > > >>> > > >>> > The thing is, flowCore doesn't use X11. It explicitly uses the >>> > non-interactive function from the feature package. But because of this >>> > dependency chain, you can't compile flowCore without having X11 >>> libraries. >>> > >>> > Even if it did, the question would be whether it's wise for a core >>> package >>> > that serves primarily to provide file I/O and representational classes >>> > should contain GUI or web-based code. I don't dispute that these can be >>> > useful. In fact, within the flow cytometry domain, the iFlow package >>> > provides a feature-rich GUI on top of various flow packages, and other >>> > packages like flowQ provide HTML output. But the core package that >>> > everybody uses in every situation, be that interactive via web, >>> interactive >>> > via GUI, or headless on a compute cluster, should not have such a >>> > dependency. >>> > >>> > >>> > > >>> > > > 2. The developer of the new package submits to CRAN instead. >>> > > > >>> > > > I would very much prefer the first solution (not least of all >>> because >>> > > > it would make my and other flowCore users' lives much easier). >>> > > >>> > > >>> > > Yes, and then we would have another package that builds on flowCore >>> > > instead of reinventing the wheel and not necessarily being >>> interoperable. >>> > > This is why we emphasize the re-use of S4 classes. >>> > > >>> > > >>> > > >>> > Yes, exactly. We have an excellent and growing collection of flow >>> cytometry >>> > data processing packages within BioC, and it would be tragic for this >>> new >>> > package not to be included in that (and to be less interoperable). >>> > >>> > >>> > > >>> > > > >>> > > > An easy way of handling it would be to remove the density gating >>> > > > functionality in flowCore, which I believe is the culprit in terms >>> of >>> > > > dependencies, and which certainly goes beyond flowCore's purpose of >>> > > > providing "vasic structures for flow cytometry data" and into the >>> > > > realm of analysis. This density gating would probably exist better >>> in >>> > > > its own package. >>> > > > >>> > > > This could be tricky, given that flowCore has over 30 downstream >>> > > > packages now, but I suspect that few if any of them actually use >>> the >>> > > > density gating functionality, and that those which do could be >>> > > > identified and their own dependencies changed concurrently with >>> > > > splitting flowCore up. >>> > > >>> > > It ought to be easy to figure it out. Maybe >>> > http://search.bioconductor.jp/can help. >>> > > >>> > > Dan >>> > > >>> > > >>> > >>> > Thanks -- yes, using that tool it's just flowViz, flowStats, plateCore >>> and >>> > iFlow. Apparently iFlow's been removed, though, so just three packages. >>> > flowViz and flowStats are actually maintained by Mike, who maintains >>> > flowCore, so transitioning wouldn't be too much trouble. >>> > >>> > >>> > >>> > >>> > > >>> > > > >>> > > > _______________________________________________ >>> > > > Bioc-devel@r-project.org mailing list >>> > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> > > > >>> > > >>> > >>> > [[alternative HTML version deleted]] >>> > >>> > _______________________________________________ >>> > Bioc-devel@r-project.org mailing list >>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> > >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> Bioc-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >> >> > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
