[BioPython] Updates to the source tree

[Jeffrey Chang]

On Mon, 1 May 2000, Brad Chapman wrote:

> > Because of the overlap in functionality, Bio/Sequence.py is being
> > deprecated in favor of Bio/Seq.py.  Code that uses Sequence.py 
> (including
> > Brad's biopython-corba stuff) will need to migrate over to the new
> > module.  Sequence.py will be removed from the tree before we do an 
> alpha
> > release, which will probably be in a few months.
> 
> The current biopython-corba actually already uses Seq.py (Andrew's 
> sequence class). Unfortunately, it also uses Andrew's SeqIO/FASTA.py 
> class, but I'll work to switch it over as soon as we can get all of 
> the parsers feeding into Seq.py. At the same time I'll also switch 
> the "biopython-lookalike" biopython-corba interface so it resembles 
> what is in cvs (right now it resembles what was in Andrew's module).

Great!  I hope this isn't too disruptive.


> > I've added in support for distutils.  It is now possible to create 
> source
> > and binary distributions for people without access to CVS.  Expect 
> that to
> > happen soon, after all authors get their code in a somewhat runnable
> > state.  I imagine we will probably use distutils to distribute the
> > biopython package once it's ready for release, unless someone wants 
> to
> > muck around with configure and Makefiles!
> 
> I was also going to try and get biopython-corba ready so it was 
> distutils friendly, but I'm not positive how we want biopython-corba 
> to be related to biopython. 

distutils was really nice to work with.  Now we have an easy way to build
packages, and users have an easy way to install them.  The down side is
that they'll need to install either the distutils package or Python 1.6,
which comes with a copy.

I still have some concerns about distutils, though.  I'm not sure whether
there's a good way to deal with testing code or how it handles
configuration.  However, I must admit that I don't keep up with the SIG,
and these might already be solved!  Anyone more up on distutils?

I'm not against using a more conventional configure/Makefile type
build/installation process for unix-like environments, provided that the
solution is reasonably cross-platform (at least Solaris, Irix, Linux) and
handles extension packages.  However, someone will need to put that
together!


> The way it is set up right now, the biopython-corba stuff would go in a
> separate directory in site-packages (Biocorba) from the main biopython
> package (which goes in Bio). The reason I thought this was a good idea
> is that then you can call the "biopython-lookalike" interface with code
> like: 
> 
> from Biocorba.Bio.Seq import Seq
> 
> So to change Biocorba code to Biopython code, you would just have to 
> drop the Biocorba part of the import. I guess we could also make it:
> 
> from Bio.Biocorba.Seq import Seq
> 
> and have Biocorba install inside of the Bio module, but this would 
> make looking at the biopython-corba code confusing. I think it is easy 
> to understand now because the biopython-lookalike interface is in a 
> totally separate Bio module from the Server and Script code.
>     So what to people think? Should biocorba go inside of Bio, or be 
> a separately installed module?

I don't have really strong feelings about it.  However, I do lean slightly
more toward integrating it with the main distribution, and letting
the user choose whether to install it as a configurable option.


>     Also I noticed that you had some SVM extension stuff listed in 
> setup.py (neat!). Are we planning on having a separate extensions 
> package for this stuff (like Bioperl). Just curious :-)

Yeah, I slipped in some classification libraries unannounced, hoping
nobody would notice them until we figure out the right way to handle it!
My feeling is that biopython should contain both library tools and
standalone scripts that's likely to be helpful to biologists.  Thus, it's
useful to also package in related algorithms that might be used in
biological applications. 

That said, I don't want to be in the business of duplicating other
people's work.  I envision that one day biopython may be be compatible
with Numpy, and may even require it for that kind of work.  However, I
certainly don't want to duplicate their functions, or require Numpy for
people doing unrelated stuff.

Jeff



> Brad
> 
> 
> 
> 
> _______________________________________________
> BioPython mailing list  -  BioPython@biopython.org
> http://biopython.org/mailman/listinfo/biopython
>