[Bioperl-l] Splits again
bix at sendu.me.uk
Thu Jun 28 12:03:54 EDT 2007
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
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
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
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.
More information about the Bioperl-l