[Bioperl-l] Bio::Assembly::IO::bowtie circular dependency?

[Chris Fields]

Dan,

It does introduce circularity, in that Bio::Assembly::IO::bowtie requires Bio::Tools::Run::Samtools in bioperl-run, but bioperl-run itself requires Bio::Root::Root.  So we'll need to decide on something...

Re: Rob's proposal: one of the long-term goals we have is to make the bioperl installations more modular and focused.  This will probably start up after I push out a 1.6.2 release and will involve splitting up and focusing modules into separate releases.  Reasons being:

(1) allowing bug fixes and updates to be pushed to CPAN faster, 
(2) reducing the overhead of donating code (it can go straight into CPAN, just declare the proper deps), 
(3) reduce the issue where the bulk of module maintenance is placed on bioperl devs (particularly core devs),
(4) start breaking the reliance many have had of using svn checkouts for bug fixes.

We can focus on specific problematic areas (for instance, FeatureIO) w/o hampering the release of other unrelated modules (SearchIO, etc).   The current set of modules will likely remain under the 'BioPerl' aegis, in that they will be maintained by the current devs and released under the BIOPERLML cpan account, with a cabal of devs/maintainers all capable of pushing a CPAN release.  This is essentially how Moose is set up, and I believe the dev and 5.12 releases of perl will also follow this route.

With that in mind, creating either a focused BowTie-specific package, or a focused next-gen specific one, does make sense.  Nothing prevents a dev from using the same general directory structure (Bio::Assembly, Bio::Tools::Run, Bio::Search::*, etc).  That would enable you to develop the code and make CPAN releases on your own timetable, instead of being bound to the (very slow) current release cycle.  

chris

On Feb 9, 2010, at 2:51 PM, Dan Kortschak wrote:

> Hi Rob,
> 
> Yes, I considered the problems involved in including B:A:IO:b in
> bioperl-live because of that. Though I don't see it as a circularity
> issue, just a straight dependency one.
> 
>> From memory (and a quick look at the .pm and .t files), in the absence
> of bioperl-run the test should just be ignored (they currently are not
> skipped - I will add that) and inclusion of the module in code should
> fail informatively, so I don't really see that as a problem. If it is
> seen as a problem though I think the best approach would be to migrate
> it to bioperl-run, rather than placing it in it's own package -
> bioperl-run already depends on bioperl-live, so all internal
> dependencies would nominally be satisfied (samtools and other
> executables are outside our control).
> 
> Other opinions?
> 
> cheers
> Dan
> 
> On Tue, 2010-02-09 at 12:27 -0800, Robert Buels wrote:
>> Bio::Assembly::IO::bowtie uses Bio::Tools::Run::Samtools, which is part 
>> of bioperl-run.  Doesn't that introduce a circular dependency between 
>> bioperl-live and bioperl-run?
>> 
>> Perhaps it should be split out into its own CPAN distribution that 
>> depends on both bioperl-run and bioperl-live?  Or maybe some way can be 
>> found for it to not use Bio::Tools::Run::Samtools?
>> 
>> Rob
>> 
> -- 
> _____________________________________________________________   .`.`o
>                                                         o| ,\__ `./`r
>  Dr. Dan Kortschak  dan.kortschak at adelaide.edu.au    <\/    \_O> O
>                                                          "|`...'.\
>  Every time I see an adult on a bicycle, I no longer      `      :\
>  despair for the future of the human race.                       : \
>    -- H. G. Wells, 1904
> 
>  By replying to this email you implicitly accept that your response
>  may be forwarded to other recipients, unless otherwise specified.
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l