[Bioperl-l] Optional 'circular dependency' ok?

Mauricio Herrera Cuadra arareko at campus.iztacala.unam.mx
Tue Sep 19 21:00:47 UTC 2006

Chris Fields wrote:
> Sendu Bala wrote:
>> Chris Fields wrote:
>>> I think any dependencies are supposed to be listed in the Makefile and
>>> DEPENDENCIES regardless of how many times they are used or if the method
>> is
>>> optional.
>> Well, the issue here is that doing that would create a circular
>> dependency; Ensembl Perl API requires Bioperl. Do the various ways of
>> installing Bioperl not 'care' about circular dependencies?
> Well, if there are circular dependencies that's a whole different ballgame.
> That's what I get for not reading the subject line!  
> Could the module be added to bioperl-ext or bioperl-run?  That would break
> the circular dependency since the Ensembl API doesn't require those; at
> least I think it doesn't.

What I remember (if my brain still works properly) is that the Ensembl 
Perl API requires Bioperl 1.2.3 to run properly (or at least to be 
installed). Ewan mentioned a couple of months ago in the ensembl-dev@ 
list that Ensembl doesn't make heavy use of Bioperl anymore, so for the 
moment they're not planning to move up to 1.5. AFAIK most people install 
the latest Ensembl code with Bioperl 1.2.3 (correct me if I'm wrong, I'm 
not really sure about this). The thread I mention was precisely about 
the Bioperl version used in Ensembl, you can see it here:


My questions here would be:

1) Will your methods be fully functional/compatible with the current 
Bioperl branch? What I try to say here is that in your particular case, 
won't the use of the Ensembl Perl API introduce the need of older 
Bioperl code? Something like a 'backwards dependency' at code level (the 
arrows mean 'requires'):

   bioperl-1-5-2 method -> ensembl-40 method -> bioperl-1-2-3 method

Here I'm assuming that you're prototyping this by using the latest 
Bioperl and Ensembl versions from CVS (*almost* every developer lives on 
the bleeding edge :)).

2) Depending on the amount of code you will use from Ensembl, why 
introducing its whole API into Bioperl? Maybe you can borrow only what 
you need from Ensembl and give credit for that.

On the other hand, I support Chris' idea of adding your module into the 
bioperl-ext or bioperl-run packages. To me it sounds good for avoiding a 
circular dependency problem.


arareko at campus.iztacala.unam.mx
Laboratorio de Genética
Unidad de Morfofisiología y Función
Facultad de Estudios Superiores Iztacala, UNAM

More information about the Bioperl-l mailing list