[Bioperl-l] Splits again

[Sendu Bala]

Chris Fields wrote:
> On Jun 28, 2007, at 2:25 AM, Sendu Bala wrote:
> Let's say we only want to install Bio::SeqIO::genbank.  The 
> Bio::SeqIO::genbank Build.PL would only install what was needed (as you 
> indicated), only Bio::SeqIO::genbank-related tests would run (along with 
> dependency test, if available), and life would go on.  However, what if 
> we wanted to install everything in SeqIO/DB/AlignIO/etc?
> 
> We could have the Bio::SeqIO Build.PL ask whether you want all SeqIO 
> modules installed or a select few (maybe a quick 'install all (y/n)?' 
> followed by a list, which installs them one at a time along with 
> dependencies), or have the option to specifically denote them as passed 
> args to SeqIO's Build.PL, something like 'perl Build.PL -install-plugins 
> genbank embl swiss', 'perl Build.PL -install-plugins all', etc.  If a 
> specific module (Bio::SeqIO::genbank) is installed directly then maybe 
> the installation q&a's of followed modules could be bypassed when 
> installing down the dependency tree with additional passed args.

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.

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.


> 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.


> 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).


> 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.