[Bioperl-l] bioperl-run; size/complexity of bioperl for 1.2

[nkuipers]

I like your (c) option.  There are three reasons for this.

1)Newbie-friendly...learning curves are supposed to be just that, curves, not 
vertical lines to the average joe, and we all want bioperl to be popular and 
used after all.
2)Disenchanted-boss-friendly.  To elaborate, my use of bioperl is entirely 
self-initiated and originally somewhat against my supervisor's wishes.  His 
past experience with bioperl was fraught with bugs and so forth (and this is 
NOT a Perl numnuts here, he's QUITE the wizard).  My use of bioperl is limited 
to core functionalities, some incarnation of which has been with bioperl for 
quite some time, like processing formats with SeqIO and parsing BLAST reports 
with BPlite and SearchIO, partly because the rest I can roll myself and partly 
because my supervisor is satisfied with me staying away from the "bleeding 
edge of development".  Having a "starter-pack" stuffed with easy-interfacing, 
robust and simple functionalities is therefore a good thing for wary bosses.
3)you get to learn some deep CVS magic ;p

Best regards,

Nathanael Kuipers
---
Center for Biomedical Research,
Dept. of Biology,
University of Victoria

>===== Original Message From Ewan Birney <birney@ebi.ac.uk> =====
>We are starting to run into a problem due to the sheer size of Bioperl;
>we have 500 odd modules in bioperl-live (perhaps better thought of as
>bioperl-core) - but some of the first "use case" problems - like running
>BLAST we have quite sensibly separated out into bioperl-run - which itself
>has some 306 modules. In bioperl-run we hope to put lots of generic run
>functionality, not least it is the bridge between biopipe and the core
>(or, in Ensembl speak, it is the runnables) and we'd probably like to put
>generic job control, primitive queue mangement and stuff in there.
>
>So... separate cvs modules - good. But... for new users... not having
>"BLAST a sequence" in the first thing they download - Bad.
>
>
>What we are struggling with is that our logical description is cutting
>across our "starting functionality" set. This I am sure is something many
>projects have faced before - does anyone know how they square this circle?
>Does anyone square this circle?
>
>
>More practically/importantly, for bioperl-1.2, do we:
>
>
>  (a) distributed bioperl-1.2, bioperl-run-1.2 and say "if you want to get
>remote BLAST parsing, you have to download and install both" (I don't like
>this - new users are getting freaked out enough just by installing one of
>these beasts)
>
>  (b) Have a bioperl-all-1.2.tar.gz, which is everything in which case:
>    - how is it structured internally?
>    - do we do this with cvs aliases or scripts
>    - does bioperl-db come in? bioperl-ext? Oh... vey...
>
>  (c) Have bioperl-1.2 being actually "starter-pack bioperl" which is a
>merge-and-prune of bioperl-core and bioperl-run (and perhaps others) and
>then distribute bioperl-live as bioperl-core-1.2.tar.gz,
>bioperl-run-1.2.tar.gz etc.
>
>
>
>Any ideas? I sort of favour (c) and am happy to write the necessary
>scripts for this and/or learn deep cvs aliasing magic for this.
>
>
>
>Basically the aim is to keep the learning curve as-flat-as-possible for
>newbies without having
>everything-in-one-cvs-module-and-everything-a-function-in-one-file for
>developers.
>
>
>
>The eternal problem for software engineers I am sure. Any thoughts out
>there?
>
>
>e.
>
>
>_______________________________________________
>Bioperl-l mailing list
>Bioperl-l@bioperl.org
>http://bioperl.org/mailman/listinfo/bioperl-l