[Biopython-dev] Developmental policies

[Bruce Southey]

Peter wrote:
> On Sat, Jan 10, 2009 at 6:31 PM, Tiago Antão <tiagoantao at gmail.com> wrote:
>   
>> By the way, another issue that would be interesting to address is
>> deprecation of older Python versions and Python 3. Like just having a
>> clear stance on what is the current feeling about this. It seems to be
>> a recurring question.
>>     
>
> Regarding older versions of python, we have stated that Biopython 1.49
> should work on Python 2.3 to 2.6, and we expect to do the same for
> Biopython 1.50.  Thereafter, we will probably drop support for Python
> 2.3 (unless anyone has a strong need for it and makes their voice
> heard).  See the mailing list archive and the corresponding new
> postings:
> http://news.open-bio.org/news/2008/11/biopython-and-python-26-and-python-23/
> http://news.open-bio.org/news/2008/11/biopython-release-149/
>
> Regarding Python 3, one hold up will be neither ReportLab nor NumPy
> have a clear plan for Python 3 - or at least that is my impression.
>   
There has been limited information on the numpy list regarding Python 3 
but there has been some investigation on this 
(http://www.scipy.org/Python3k). I did ask about Python 3 last year in 
the thread titled 'Report from SciPy' and Robert Kern's response should 
be at:
http://www.mail-archive.com/numpy-discussion@scipy.org/msg12101.html

Also, this thread has the future aims of numpy (obviously still awaiting 
scipy 0.7):
http://www.mail-archive.com/numpy-discussion@scipy.org/msg12091.html

Currently I think the main current effort for numpy 1.3 is getting 
Python 2.6 fully supported (windows is the main problem) before there 
will be any further consideration of Python 3. One of the main problems 
is that numpy uses a few APIs that are depreciated in Python 3. So any 
porting will not go far until the correct APIs are used which is 
probably be after the next numpy release.

> However, even ignoring those parts of Biopython which use NumPy (e.g.
> Bio.PDB and Bio.Cluster) and Bio.Graphics (the only use of ReportLab),
> we have a lot of useful code.  In the short term we should be aiming
> to have everything run under Python 2.6 in warnings mode, as a step
> towards eventual Python 3 support.
>   
While I understand this approach, I do wonder how effective it will be 
compared to direct porting using the 2to3 tool. One reason is that 2to3 
is more than a code convertor as it also attempts to guess at what you 
are trying to do.

Anyhow, this is not a trivial task and I am willing to help in that regard.
 
> Beyond that, I think that it is likely we'll want to use bytes rather
> than (unicode) strings in Python 3 for the Seq object, but have not
> given this much thought.
>
>   
>>>> 5. Legal issues
>>>>         
>>> Try and avoid them?  What did you mean in particular?
>>>       
>> In my opinion something should be said about this. Actually I think
>> (suggest) it is essencially a matter of mainly taking Bruce' s
>> comments (e.g. one cannot have derived works of non-free software) and
>> write them down on a wiki page. Just things potential contributor
>> would have to be aware of on a legal front.
>>     
>
> I see what you mean.  Perhaps I am naive in thinking this should be
> common knowledge amongst potential contributors.
>   
I think we must be explicit in this and ensure that any accepted code is 
BSD-compatible because we can not ensure what people really know. 
Further the license of any application that Biopython interacts with 
must be clearly stated and the developer is responsible to get one if it 
does not have one. That way we know what is included and should help 
users as well in terms of whether or not they can use some application.

>   
>>> Testing:
>>> I'd strongly resist adding any new module without an accompanying
>>> test, and wish this had been a firm policy from day one.
>>>       
>> People should also be encouraged to test (in as much as possible) in
>> at least Win/Linux/Mac. Of course, for some people it will be
>> difficult as access to all platforms is not always possible for
>> everybody. But at least encouragement should be made...
>>     
>
> Also tests which require additional setup are a pain.  The BioSQL
> tests are an example of this, where it is unavoidable - but any
> situation like this reduces the number of people/machines where that
> test will get checked.  Michiel has stressed this kind of thing as a
> concern in the past (as I recall).
>
> Peter
>
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biopython-dev
>   
We can not force people to run tests but hope that sufficient people who 
do cover many of the variations as possible. Do we need to create 
buildbots (eg http://sourceforge.net/projects/buildbot/)?

I do not test or use BioSQL code because I do not use BioSQL and do not 
run a compatible database on my system. So it would be really great if 
BioSQL supported sqlite because the database requirements would be 
alleviated.

The other related aspect is that certain applications like clustalw must 
be in the path otherwise the application will not be found and the test 
skipped. But I do not know how to solve this except perhaps using 
environmental variables.

Regards
Bruce