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
