[Bioc-devel] Dependency on windowing systems in the flowCore package

[Dan Tenenbaum]

Hi Kieran,


----- Original Message -----
> From: "Kieran O'Neill" <koneill at bccrc.ca>
> To: bioc-devel at 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.

[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]


> 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. 



> 
> 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


> 
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>