[BioLib-dev] GSL

[Chris Fields]

On Aug 5, 2009, at 9:29 AM, Hilmar Lapp wrote:

>
> On Aug 5, 2009, at 2:07 AM, Pjotr Prins wrote:
>
>> On Tue, Aug 04, 2009 at 07:32:31PM -0400, Hilmar Lapp wrote:
>>> Hi Pjotr - many systems come pre-installed with GSL these days. Is  
>>> it
>>> really wise not to just assume it as a system dependency?
>>>
>>> 	-hilmar
>>
>> That is a call we have to make. There are two problems with these
>> type of dependencies:
>>
>> (1) libraries change
>>
>> (2) on different systems they are in different places
>>
>> The main reason I like to have the source base inside biolib is that
>> when we do a release we have ONE source base. So bugs can be found,
>> without the added complexity of (1).
>
> You're really just shifting the complexity of (1) from the system  
> administrator of a user's (or developer's) machine to yourself as  
> the Biolib maintainer (or whoever comes after you). As not  
> infrequently the user doubles as the sysadmin on her machine, this  
> is of course nice for the Biolib user.
>
> However, it does create an additional burden, and especially  
> responsibility, for the Biolib maintainers. I'm not convinced that  
> fulfilling that responsibility is one of the best ways Biolib  
> developers and maintainers can spend their time.

I do have to second this.  Also, many libraries come with some kind of  
config check available (what version the lib is, where the headers/ 
libs are, etc).  This wasn't available when bioperl first added io_lib  
support.

Also doesn't help when said code goes largely unmaintained (bioperl- 
ext is essentially deprecated b/c of bitrot).

>> Especially over time this is a great concern. On the Perl mailing  
>> list you encountered that this year with the staden_io_lib module -  
>> the interface changed.
>
> I know. But it's also a very common situation that we all have to  
> learn how to deal with anyway. Bio::Graphics needs a certain version  
> of GD. Most systems come pre-installed with GD but in a version  
> that's too old, so most people end up having to upgrade their GD, or  
> install a newer version in parallel and then make sure their  
> environment is correct when compiling the GD perl bindings etc. The  
> same is typically true for DBI and the various DBD drivers. There  
> are numerous other examples.

The same happens with perl itself.  Due to worries about backwards- 
compat issues they have put off 5.10.1 for over a year now (it was due  
last summer).

After a lot of back-and-forth (and a few resignations) the process is  
moving forward again, and 5.10.1 is imminent. The overall opinion is  
if a user wants the latest module updates, and if said module requires  
5.10, they will need to upgrade to 5.10.

>> [...]
>> With (2) is a particular concern since bio* developers are all over
>> the place: different distros of Linux, OSX, Cygwin, Windows. Having
>> the source tree in biolib kills those birds with one stone.
>
> If there are no problems. As soon as there are (and there are bound  
> to be if the library is under active development) there may be more  
> birds to kill than you have stones (or time) for.
>
>> [...]
>> So in it goes, as far as I am concerned. If only for the fact the I
>> only want the latest and greatest :-)
>
> The other benefit that treating it as an external dependency has is  
> tempering that desire for the bleeding edge. The bleeding edge cuts  
> well, but it's full of blood too.

If anything the reliance of users on bioperl's bleeding edge code  
(bioperl-live) has slowed development down to a crawl, and was the  
impetus for me to push a 1.6 release out ASAP (and the reason we have  
decided on restructuring bioperl for easier releases).

Users who want bleeding edge code should expect bugs, possible API  
changes, etc.  They get kudos for pointing out the bugs, sure, but I  
start pulling my hair out (what little I have on my head still) when I  
hear "Bio::Module::Foo in bioperl-live breaks or throws an error in my  
production code."  It doesn't happen often, but enough to be  
frustrating.

> That all being said, having the GSL SWIG-mapped as a first class  
> library in Biolib so that all Bio* projects can take advantage of it  
> would be very cool in its own right.
>
> 	-hilmar


Agreed.

chris