[Bioperl-l] [Gmod-gbrowse] Bioperl 1.6 and Bio::Graphics

Chris Fields cjfields at illinois.edu
Tue Dec 2 12:07:43 EST 2008


> Hi Chris,
> I am supportive of splitting out Bio::Graphics, but not the  
> Bio::DB::* modules before the 1.6 release. The only dependency issue  
> is the module Bio::Graphics::FeatureBase, which is a lightweight  
> hash-based Bio::SeqFeatureI module that is shared between  
> Bio::Graphics::Feature and Bio::DB::SeqFeature. It should be renamed  
> and kept in the main bioperl distribution.

Okay, we can do that.  Would you want that to be under bio-graphics in  
subversion, or should we think ahead a bit in case other Gbrowse- 
dependent modules migrate there and call it something else?

> Will it confuse people if I rename this module Bio::SeqFeature::Lite?

Bio::SeqFeature::Lite works for me.  I can't see that causing too many  
problems as long as Gbrowse installation always picks the latest dev  
or CPAN release based on the version (though I don't know if there are  
any documentation fixes we need to take care of, maybe on the wiki).


> Lincoln
> On Wed, Nov 26, 2008 at 3:25 PM, Chris Fields  
> <cjfields at illinois.edu> wrote:
> On Nov 26, 2008, at 12:37 PM, Scott Cain wrote:
> Hi Chris,
> While the decision ultimately rests with Lincoln (as, presumably, will
> most of the work :-)  I'm not sure I agree that the split needs to
> happen before the 1.6 release.  Consider the case where GBrowse 1.70
> requires a newer version of Bio::Graphics than is available in
> BioPerl.  We would put a version requirement in the Makefile.PL for
> Bio::Graphics::Panel to be some number greater than the current
> BioPerl release and put it on cpan.  Users would then do the cpan
> shell shuffle, and get the right version of Bio::Graphics, and if they
> don't already have BioPerl, they'll get that too (with an older
> version of Bio::Graphics that will be immediately overwritten).  Is
> there a flaw (or horrible user experience) in my thinking?
> Scott
> Sorry Scott, forgot to mention it wouldn't just be Bio::Graphics.   
> Lincoln also mentioned Bio::DB::GFF and Bio::DB::SeqFeature::Store  
> (basically anything Gbrowse-related) would be included, so maybe bio- 
> gbrowse or similar would be a better name.
> If you like we could postpone a split (less work for the release).   
> A split bio-gbrowse release would just overwrite the older modules  
> as you mention.  However, I plan on having regular point releases to  
> CPAN; how do we want to handle Gbrowse-related bug fixes in a point  
> release down the road, after a Bio::Graphics split?
> Do we stop Bio::Graphics fixes at a certain point after a post-1.6  
> split so an installation script always finds the latest  
> Bio::Graphics::Panel?  Or do we want to merge those fixes into the  
> point release regardless, just in case?
> chris
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
> -- 
> Lincoln D. Stein
> Ontario Institute for Cancer Research
> 101 College St., Suite 800
> Toronto, ON, Canada M5G0A3
> 416 673-8514
> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
> Cold Spring Harbor Laboratory
> 1 Bungtown Road
> Cold Spring Harbor, NY 11724 USA
> (516) 367-8380
> Assistant: Sandra Michelsen <michelse at cshl.edu>

More information about the Bioperl-l mailing list