[Bioperl-l] Bioperl partitioning (was Re: SVN and ...Re: Perltidy)
Chris Fields
cjfields at uiuc.edu
Wed Jun 20 01:48:20 UTC 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
GBrowse/GFF.
>> 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.
chris
More information about the Bioperl-l
mailing list