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

[Ewan Birney]

On Fri, 22 Nov 2002, nkuipers wrote:

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

(interesting note: SearchIO is pretty recent, but it is stable and written
well by Jason. just don't tell your boss ;))


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