Talk:Proposed BioPerl changes

From BioPerl
Jump to: navigation, search

Place ideas, discussion, on the proposed directions the restructuring. Please place a signature after comments for tracking.

Contents

Suggestions

Bio::DB::SeqFeature

I think Bio::DB::SeqFeature should be split off -- this lets changes there be propagated in support of Gbrowse release schedules as well.

Bio::SeqIO dependency graph

Image was generated from the latest bioperl 1.6 SVN branch using Module::Dependency.

pmd_grapher.plx -t -b -s Bio::SeqIO -o ./bioperl.dat SeqIO_graph.png

SeqIO graph.png

  • Ack! --maj 14:09, 20 July 2009 (UTC)

Original proposed split(s)

This is now somewhat outdated and is here for historical reasons

Here's my (slightly revised after sleeping on it) idea for a bioperl module split:

The main page details the modules we consider core vs. potentially non-core vs. unstable/unmaintained. Anything non-core could be moved to new, separately installed, optional distributions. How far do we want to eventually take this? And what do we mean by 'core'?

For the 1.6 release, I think we could spin off stable (but noncore) code into one distribution and experimental/untested/undocumented bleeding-edge code into a separate distribution. For this I'll refer to them as 'bioperl-main' (stable-noncore) and 'bioperl-unstable' (unstable-developer), which sounds more appropriate to me. BTW, the names and number of these separate distributions has not been officially decided as of yet; for instance we have also used names like 'bioperl-tools'/'bioperl-dev' (for stable-noncore and unstable-developer code, respectively).

A bioperl-main distribution would require the core modules as a prerequisite, so it would be similar in vein to the old-style 'core' distributions. bioperl-unstable, likewise, would require bioperl-main (and hence bioperl-core), and may not be installed by default.

 'bioperl-unstable' --> 'bioperl-main' --> 'bioperl-core'

The upside of this (in my opinion) is that we may increase the release schedule cycle if core stays relatively stable. For instance, the most significant updates would be to bioperl-main or to bioperl-core; updating could require one or the other. It also allows us to test implementations in bioperl-unstable without breaking more stable code further down the chain. For instance, moving code from bioperl-unstable to bioperl-main would require decent test coverage and docs; significant code changes and additions to bioperl-core would require more rigorous standards (probably discussion amongst core devs on and off-list, maybe including beer and bar snacks).

The downside may be initial confusion for users who may install bioperl-core instead of bioperl-main and will not get the modules they want (either b/c they are in bioperl-main or are in unstable). Versioning also has to be worked out. For instance, if bioperl-core stays stable but bioperl-main changes, do we increase the versions for both, or do we change the version of only one? How do we determine what constitutes a significant release (a 1.x) vs. a point release (1.x.y)?

A few questions off the top of my head:

  • What is 'core'?

I think that's pretty subjective; it's important to discuss it openly on the list.

In my opinion 'core' means the very basic set of modules w/o extraneous dependencies. For instance, I think of core as being SeqI/PrimarySeqI, AlignI, SeqFeatureI, AnnotationI, and anything they require (and pretty much nothing else). That cuts out XML/HTML parsers/writers, database functionality, remote-server access using LWP or SOAP, and other non-bioperl-related modules that aren't in the perl core. Others would include parsers in there as well, though introducing those potentially also introduces dependencies.

  • Where do bioperl-db, bioperl-network, bioperl-run, and the others fit in?

This I'm not sure of. I could see bioperl-db and bioperl-network fitting into bioperl-main, with the bioperl-run wrapper modules and bioperl-ext as a separate installation. That would be up to Brian and Hilmar, really, and it may be easier to maintain them as separate installations.

--Chris Fields 14:14, 14 February 2008 (EST)

Personal tools
Namespaces
Variants
Actions
Main Links
documentation
community
development
Toolbox