[Bioperl-l] Splits again

[Chris Fields]

On Jun 28, 2007, at 11:03 AM, Sendu Bala wrote:

> ...
> I'd probably stay away from something like this. My primary reason  
> being, off-the-top-of-my-head I don't see how to get it to work. If  
> you're installing Bio::SeqIO for the first time via CPAN you can't  
> ask it to install Bio::SeqIO::genbank et al. at the same time  
> because Bio::SeqIO::genbank depends on Bio::SeqIO, giving us some  
> circularity.

True...

> I also wouldn't want these things to be complicated. There should  
> be little in the way of questions to ask during install. Each  
> module's Build.PL should be ultra-simple with no advanced logic at  
> all. It should just specify things that are absolute requirements.  
> This simplicity helps avoid some of the problems we face by  
> distributing the monolithic Bioperl.
>
> No, much better for us and for users to provide a Bundle::Bio-SeqIO.

I just don't want too much Bundle-itis as it'll gets confusing for  
newbie (i.e. Vista-itis, or AdobeCS-itis).  It should be limited to  
functional grouping (SeqIO, AlignIO, DB, etc), 'install everything',  
or distribution-specific (GBrowse).

I also think (though Hilmar may veto this) that we should work on  
integrating bioperl-db, network, etc. into this if it goes forward.

Here's a question: how do we plan on handling uploading bioperl  
updates to CPAN via PAUSE?  Do we want to run every single module  
through one pumpkin?  Or do we want to have a core dev group PAUSE  
account?  I can see, for instance, removing everything EUtilities- 
related and submitting it independently using my own PAUSE account,  
but it would be nice to have it under an umbrella 'bioperl-devs'  
account instead.

>> Now, this doesn't address several related issues, such as how we  
>> handle versioning of the independent modules (should be in a  
>> controlled manner),
>
> When a module is changed, it gets a version bump. Nothing  
> complicated needs to be done. Transparent and obvious, behaving  
> like all other CPAN modules would be my choice.
>
>> what we do about deprecated modules which linger about on CPAN,
>
> Delete them from CPAN seems appropriate.

I know you can do that via PAUSE, but I think it lingers about on  
search.cpan.org (unless that's been fixed).  This would prob. have to  
be used sparingly.

>> how we deal with PPMs/RPMs/packaging, and so on.  All have  
>> possible reasonable ways they can be addressed, I believe.  Also,  
>> I think we should still think about doing regular full-scale  
>> 'stable' (1.#) releases (sort of our stamp of approval for that  
>> batch of modules at that point in time, with a reasonable 'sell- 
>> by' date).
>
> Yes, we can still choose to take a snapshot and announce it to the  
> world, but at the module-level nothing special would happen. There  
> would just be an updated Bundle::Bioperl-everything (or whatever).

Right, it would basically be a stamp of certification.

>> Again, it should be seriously discussed among the core devs and  
>> the bioperl community at large prior to any serious work on it,  
>> and it would be quite a large-scale project, but possibly worth  
>> it.  It can only go forward if there is enough momentum behind it.
>
> The requirement for this approach is per-module test scripts. Which  
> as I identified already, is very desirable anyway so we can hit  
> 100% test coverage.
>
> So, regardless of anything else can we all agree that per-module  
> test scripts are a good idea and should be worked on? If so, I'll  
> look into the feasibility and figure out how much work will be  
> involved.

I think so, but the feasibility issue is critical.  Do we want cvs/ 
svn to be divided up into 900 subdirectories (one for each module),  
or do we want to have a similar directory structure as we have now,  
but with each module in it's own directory?  Or leave everything as  
is and generate Build.PL on-the-fly (prob. least feasible)?

This is where it might be wise to do it piece-meal at first (maybe  
starting with something somewhat segregated like Bio::Tools), then  
progress from there.

chris