[Bioperl-l] Splits again
cjfields at uiuc.edu
Thu Jun 28 13:17:50 EDT 2007
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
> 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'
>> 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
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.
More information about the Bioperl-l