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
