Bioperl: Module collections...
Sat, 1 Aug 1998 11:01:50 +0100 (BST)
[For people on the list who are wondering if they should leave on basis of
high traffic - or what looks like will become high traffic - we are
setting up a mailing list called bcd-perl-guts really for people who will
be actively using the CVS system. The posts will be archived and open for
everyone to see, and we will still use this mailing list for the more
general and less 'gutsy' stuff...]
On Fri, 31 Jul 1998, Steve A. Chervitz wrote:
> The name change should coincide with a functionality change, namely,
> adding a feature description mechanism. We'll have to hear from ChrisD
> and Ian about their progress along these lines.
In my opinion the feature description stuff *should not* be in the Seq
object (the 'light-weight' sequence object) but in the heavyweight
sequence object (what I call the 'Entry' object). My game plan has
PreSeq.pm -> Seq.pm (light weight object) from Chris
Entry.pm -> Ian's object adapted from his GSC objects that
has features (and taxonomy and the kitchen sink...).
I think this is a much cleaner way of breaking up the problem than
simply having a single heavy weight object. Entry.pm can have alot of
'magic' whereas Seq.pm should be lean and mean. (Of course Entry.pm
should contain Seq.pm)...
From this point of view PreSeq can become Seq now, which is what I
reckon. Other votes? (before Wednesday by any chance?)
> > b) Stevec's Blast module
> > This use's Steves Bio::Root::Global (at least) and ??
> > Bio::Root::Object
> > Steve - can we get rid of these things? (Do you want to?)
> Well, my modules rely on these so they are a necessary part of my Blast
> distribution as it currently stands. You could put my Bio::Root directory
> under CVS as well (it's bundled with my Blast distribution). Removing
> them from my design would take a fair bit of non-trivial de-engineering
> that I would hesitate to do (but would consider if people complained loud
> enough :).
Consider one complaint lodged ;) - but I am certainly not obsessive about
it. I don't think we can really try to coordinate everything through
Bio::Root which means Bio::Root *really* is Bio::SteveC::Root ;) --->
Lets work with the entire Root and Object (Root and Branch?) of the
Blast.pm and see if we can trim it later on (with your blessing ;)).
For the moment shall we put the entire Blast stuff into the repository
as it stands, then you can do a checkout, merge and commit for the new
stuff, or does it make more sense to wait and perhaps for you to attach
the directories yourself once we have made the CVS system? Your choice...
> > [ snip ]
> > Once we have a CVS system up the core group can start maintaining
> > things from the CVS system. I *hope* that a clean dump of the CVS
> > system will be a clean build with a
> > perl Makefile.PL
> > make, make install
> > but who is our Makefile.PL guru ( its not me!) to get this thing to
> > recurse into directories (or does it anyway. I'm slightly in awe of
> > Makefile.PL).
> The make process will recurse automatically. Let me know if you run into
> specific problems. (I'm no guru but I have some experience with it).
> > Stevec - do you want to write bioperl.pod and the README (you seem the
> > natural person for it as leader etc...)?
> I can come up with a draft. Do you have some ideas in mind for what these
> documents should say?
I think bioperl.pod should be like the perl.pod in the distribution -
a) A header of links into the other Bio:: classes (split into
two groups - Core distribution and contributed)
b) Introduction to bioperl like --->
bioperl uses perl (and here is where to get it?)
bioperl is not an executable it is an extension of perl
The main objects (and docs) with a breif description
of how they fit together
The core group and other html resources.
c) some light hearted jokes about doing the Camel genome in the
=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/
For info about how to (un)subscribe, where messages are archived, etc: