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 <
kasperdanielhansen@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 <kevinushey@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 <koneill@bccrc.ca> wrote:
>>
>> > On 10 April 2014 14:26, Dan Tenenbaum <dtenenba@fhcrc.org> wrote:
>> >
>> > > Hi Kieran,
>> > >
>> > >
>> > > ----- Original Message -----
>> > > > From: "Kieran O'Neill" <koneill@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]]

