[Bioperl-l] Priorities for a bioperl-1.6 release
Chris Fields
cjfields at uiuc.edu
Sun Mar 23 14:17:56 UTC 2008
On Mar 18, 2008, at 10:32 AM, Sendu Bala wrote:
> aaron.j.mackey at gsk.com wrote:
>>> Or is the split intended to be 'core' == "anything and everything
>>> that was in 1.4", '????' == "everything else"? In which case,
>>> what's a good name for "modules created after 1.4"? 'crust'? ;)
>> Nah, "icing".
>> a module "use" map might be very useful to help identify "core" vs.
>> other layers of mantle/crust/icing.
>> http://www.perlmonks.org/?node_id=87329 http://search.cpan.org/src/NEILB/pmusage-1.2/
>
> Thanks for those. Neither could quite cope with BioPerl, but I've
> munged
> them together and hacked up 'module_usage.pl' which I've just
> committed
> to the maintenance directory of bioperl-live.
>
> module_usage.pl ../Bio
>
> Produces:
> *warning, may crash your browser; download it and view in a dedicated
> image viewer*
> http://bix.sendu.me.uk/files/module_usage.jpeg
> http://bix.sendu.me.uk/files/module_usage.txt
>
> ...
>
> I haven't done any full analysis along these lines and leave as an
> exercise for the interested reader for now ;)
I'm coming into this late (just got back) but I agree, this would be
very useful. Your updates based on Aaron's comments help quite a bit.
> Chris Fields wrote:
>> http://www.bioperl.org/wiki/Talk:Proposed_1.6_core_modules
>> I'm pretty flexible on any of that; it's a proposal only and I think
>> some of it may be wrongheaded, but hey, I'm willing to take a few
>> rotten tomatoes. The key issue is we should try to work out what we
>> mean by 'core' or the core library. I have a rather extreme view of
>> it as being the bare essentials without external, non-perl core
>> dependencies (only SeqI/PrimarySeqI, AlignI, AnnotationI, SeqFeatureI
>> and required modules for those classes) but I'm sure others would
>> lump in parsers, DB functionality, etc. I basically suggest placing
>> those (and any stable but potentially non-core code) in a
>> 'bioperl-main', with any unstable or untested code going into a
>> 'bioperl-unstable'.
>
> My thoughts are along these lines:
> # I agree that core should have no external dependencies
> # I agree that it might mostly be interfaces
> # It should represent a framework with all the interfaces (that have
> stable APIs), directory structure and base classes that everything
> else relies on
> # It might not do much useful bioinformatics, but provides just about
> everything needed for a dev to create a new module that does
Yes, that's essentially the idea.
>> In essence, bioperl-main would require core and resemble a stable
>> release; bioperl-unstable would require bioperl-main (and core) and
>> resemble a dev release. Not sure how versioning would go or if this
>> is a viable option at all, but it's worth discussing.
>
> # I agree that this 3-way split seems reasonable
> # bioperl-main would consist primarily of the 'leaves' of the module
> tree, mostly parsers and the like which, whilst 'stable' and tested
> should still be split away from core because the data sources they
> parse could change format slightly
> # bioperl-unstable, better bioperl-bleed, would feature brand-new
> stuff, be it new parsers for totally new formats, new APIs that do
> something not thought of before etc. When they are complete, bug-free
> and have stood the test of time they get moved into bioperl-main.
> (It is not a place for all new commits; bug fixes to something in
> bioperl-main would be committed to bioperl-main)
> # The current splits (bioperl-run, bioperl-network etc.) do not get
> their own core and bleed variant. Anything they need for core
> functionality would enter the single bioperl-core, anything new
> would enter the single bioperl-bleed, and anything stable would
> be in their own bioperl-[package]
>
> Discuss :)
We can work on updating the plan via the wiki as well as the mail
list. I find it easier to track; we can always link back to the mail
list when needed.
http://www.bioperl.org/wiki/Proposed_1.6_core_modules
http://www.bioperl.org/wiki/Talk:Proposed_1.6_core_modules
chris
More information about the Bioperl-l
mailing list