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

[Nathan S. Haigh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Fields wrote:
> 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.

Personally, I think this use of Bundle::Bioperl is more in line with
what CPAN Bundles were meant to do - "a bundle is a collection of
modules that comprise a cohesive unit". Under that definition you could
probably put the whole of Bioperl but I won't go there! When a package
is updated and a new release is made, this should be
installable/updatable via cpan as well as updating the bundle with the
correct version. This was you can get all of Bioperl via the bundle, or
just install the sub-packages on their own.

If the switch over to svn takes place, will all the Bioperl-* projects
move over at the same time? If so, will they go into their own svn
repository or into the same one? Since with svn you can checkout any
subtree of the repository I'm not clear on the pro's and cons of either
of these options.

Am I right in thinking that there is a way for cvs to define a "project"
such that when you checkout that "project" it actually checks out
multiple projects behind the scene? I'm sure I've seen this somewhere,
possibly when the project is dependent on some 3rd party code that is
also in cvs. If this is possible, I'm sure it will also be possible with
svn. This could then allow something like the following to happen after
the split up of Bioperl. The following projects could be defined:
bioperl-core, bioperl-graphics etc. Issuing a checkout of a "project"
called "bioperl" would actually checkout the real projects call
bioperl-core, bioperl-graphics etc. I may just be dreaming, but it seems
that this ought to be possible, doesn't it?


> 
>>> 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 sam. e 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
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGeMm7czuW2jkwy2gRAi+CAJ9cNZ70GojV7eviRjdWTFLk/MKYoACg2Ls4
op9sQTZyeK6G6taFhTAPMYc=
=7NRw
-----END PGP SIGNATURE-----