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

[Chris Fields]

On Sep 19, 2006, at 5:25 PM, Sendu Bala wrote:
...
>> 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.
>
> Well, bioperl-ext is described as being for Bioperl C compiled
> extensions. I suppose that instead of being a simple method in my
> module, I could create a whole new module in bioperl-run that was
> essentially a simplified front-end to what I needed Ensembl for,
> treating it like an external application?
>
> I don't think either is really an appropriate 'fit'; what is wrong  
> with
> simply not listing the Ensembl API as a dependency in Makefile.PL?

I think there are a few modules in bioperl-run which don't  
necessarily fit.  Regardless, it's up to you.

> Aren't there already optional things in Bioperl that only begin to  
> work
> after you read the instructions and manually install something? Well,
> there must be, since I've had to do exactly that to get all tests  
> in the
> suite to run (and not just skip).

There shouldn't be!  All dependencies should be found in the  
Makefile.PL and listed in the INSTALL file dependencies.  Using 'perl  
Makefile.PL' doesn't force you to install them, but it does warn you  
what Bioperl classes require them if they aren't present.

I think the large dependency list is the reason there is a separate  
Bundle::Bioperl installation.  And, even then, I don't get abi.t and  
other similar tests to work b/c they require bioperl-ext (which I  
find too much of a bother to install, really).

Christopher Fields
Postdoctoral Researcher
Lab of Dr. Robert Switzer
Dept of Biochemistry
University of Illinois Urbana-Champaign