[Bioperl-l] Smaller Bioperl Modules

[Chris Fields]

On Jul 28, 2008, at 6:06 AM, Alex Lancaster wrote:

> ...
> CF> So something like what we indicate in the below link would be
> CF> okay?
>
> CF> http://www.bioperl.org/wiki/Proposed_1.6_core_modules
>
> Yep, that was what I was referring to as the "previously discussed"
> plan, assuming that you end up with 3 tarballs: bioperl{-core} (?),
> bioperl-tools, bioperl-dev.
>
> In Fedora-land they would be named:
>
> perl-bioperl (the core package probably doesn't a qualified name as it
> is the base package), perl-bioperl-tools, perl-bioperl-dev
>
> That's quite manageable and there is a precendent on most Linux
> distros with gstreamer's (Linux's media library) split up of audio
> plugins into gstreamer-plugins-{good,bad,ugly}: http://gstreamer.net/
> based on quality (and to some extent on the basis of license, but that
> shouldn't apply to bioperl).

Exactly.

> One question: how would bioperl-run (and the other modules) factor
> into this scheme?  Would you just keep those together at the moment?
> Would bioperl-run depend only on "core" or would it also need
> bioperl-tools or bioperl-dev?

bioperl-run is (in general) a collection of 'wrapper' modules for  
running outside programs, such as EMBOSS, HMMER, FASTA, etc.  I think  
it would be best to keep those as-us as an independent distribution;  
it would depend on core.

With bioperl-db, bioperl-pedigree, and bioperl-network, we can keep  
those separate or incorporate them in depending on how Hilmar/Jason/ 
Brian feel about it.  As for the other distributions, I think we can  
set an active deadline (soonish) for someone to step up and maintain  
them, otherwise we should salvage what we need from them and deprecate  
usage for the rest.  For instance, functionality for the bioperl-ext  
modules probably should be replaced with code from the BioLib  
initiative (http://biolib.open-bio.org/wiki/Main_Page).  bioperl- 
microarray can best be replaced with perl-based interaction with  
BioConductor/R (or use pure-perl-based solutions such as CPAN's  
Microarray).

> Also could each of these separate packages be updated independently
> (i.e have different version numbers in principle)?
>
> Alex

We should have the same major release numbering (1.6, 1.7) for all of  
them, but each could have separate minor releases (1.6.1, 1.6.2, etc)  
based on bug fixes or small non-API-related changes.  If we maintain a  
dependency chain (dev and tools relies-on core), we can increment the  
version requirement for each as needed.

chris