[Bioperl-l] [Gmod-gbrowse] Bioperl 1.6 and Bio::Graphics
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).
> 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?
> 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?
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> 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