[Bioperl-l] Bioperl partitioning (was Re: SVN and ...Re: Perltidy)

Chris Fields cjfields at uiuc.edu
Tue Jun 19 21:48:20 EDT 2007

On Jun 19, 2007, at 4:57 PM, Hilmar Lapp wrote:

> On Jun 19, 2007, at 5:15 PM, Chris Fields wrote:
>> There should also be a consensus between the core devs on this; I
>> don't see it going very far w/o Lincoln, Jason, Hilmar, etc. voicing
>> their opinions
> The problem I have increasingly had with BioPerl (aside from the fact
> that it's written in Perl ;) is the plethora of dependencies I need
> to install, not the number of modules.
> But every time I've been told that that's what Perl is all about, and
> I should shut up and install the bundle. Idiosyncratically I don't
> like bundles that clutter up my hard disk with stuff I'll never use,
> and in this sense if BioPerl is divided into 10 packages I will have
> to think about each one whether I need it, and do a separate CVS
> checkout - and regular update - of each one (though granted, I
> believe there are ways the multiple checkout and update thing can be
> taken care of).

I agree; the fewer dependencies the better.  We could divide it up  
into a small, focused core package with only a few dependencies, and  
1-3 more containing the focused bits which require the most  
maintenance (Graphics, SearchIO/Tools, etc).  I worry about having  
too many more.

> In reality, this may be a rapidly disappearing trait though of those
> who have grown up in a time when they proudly spent all their savings
> to buy that new computer because it had a 20MB hard disk, compared to
> the two 360k floppy drives the previous one had.
> So don't ask me, just don't make it too hard for the dinosaurs.

There would need to be some way of getting an old-style full-blown  
core installation regardless of how many subdistros we would divy  
core up into.  My thought for CPAN was having Bundle::BioPerl take  
over this but I'm not sure if it's still being used.  Maybe there are  
other ways for svn/cvs.

>> as it will directly impact projects which rely on core
>> functionality (GBrowse/GMOD, bioperl-db, etc).
> Well, I hope there are ways to limit that?

I believe so, yes, particularly for bioperl-db.  I would think  
splitting off Bio::Graphics or Bio::DB* will have some effect on  

>> I also agree with George that this should be postponed until after
>> svn issues are taken care of.
> I agree entirely. Please don't throw this in the same bin or tie one
> to the other. The migration is neither easier nor faster nor better
> testable with a partitioned BioPerl.
> 	-hilmar

We def. have to complete transition to subversion first, then think  
about this some more.


More information about the Bioperl-l mailing list