[Bioperl-l] Splits again

[Chris Fields]

On Jun 30, 2007, at 4:32 PM, Sendu Bala wrote:

> Hilmar Lapp wrote:
>> On Jun 28, 2007, at 3:19 PM, Sendu Bala wrote:
>>> [...]
>>> Very definitely the latter. The key benefit of my approach is  
>>> that  the organisation stays as is and that a snapshot of the  
>>> repository  remains a single directory of modules in Bio so that  
>>> people don't  have to 'install' Bioperl, they can still just  
>>> uncompress the  archive (or check out the package from svn) and  
>>> point their  PERL5LIB to the root dir of the package.
> [snip]
>> In this sense, I understand a release pumpkin will generate ~900   
>> packages to upload to CPAN? How much hassle is that compared to  
>> what  uploading a bioperl release means right now?
>
> I'd have to investigate. I did my uploads using the PAUSE website,  
> which for 900 packages would be unfeasible. Will have to see if the  
> process can be automated.

Not that they would care one way or another but maybe we should  
contact the CPAN maintainers to get their thoughts.  They might have  
some ideas...

>> How brittle is all the Build.PL code that will be needed to  
>> automate  all of this, and how difficult will it be to maintain?  
>> For example,  if someone adds in 10 new modules, what Build.PL- 
>> related work will  need to be done?
>
> Well, my plan will be that once the work is done, you won't need to  
> touch the Build.PL code again. My intent is that the pumpkin can  
> just type one command and not think about anything.
>
> As for the reality, I won't know until I think about it properly  
> and experiment.

A good experiment for a branch.  I still think this could be  
accomplished step-wise; for instance run a quick test using something  
with a simple dependency tree like Bio::Root::Root (only needs  
RootI), finish up with Bio::Root*, then work down into PrimarySeq,  
Seq, etc.  Submit them to CPAN piecemeal or in batches (all  
Bio::Seq*, so on).

If the Build.PL, etc are to be generated on the fly then maybe there  
should be a simple way of registering or matching tests to modules  
(or vice versa) to ease the pain, particularly for new code.

chris