[Biopython-dev] Developmental policies

Tiago Antão tiagoantao at gmail.com
Sat Jan 10 18:31:05 UTC 2009

> mxTextTools changed their API between 2.0 and 3.0).  Similarly they
> can restrict the distribution of Biopython (e.g. NumPy isn't get
> available on Windows for Python 2.6), and will also be a potential
> road block for moving to Python 3.  As another example, a small part

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.

>> 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.

> 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...

> I'm sorry if you've had that feeling.  However, circumstances change.
> As I recall when you first asked about using SciPy as a dependency,
> Biopython was still using Numeric instead of Numpy - so using SciPy
> had to wait until after that transition.  Now that we have moved to
> NumPy, I think you have a much stronger case.

Boss, don't say sorry, I think everybody would agree that you make a
most fantastic effort.

Regarding circunstances: When circunstances change, then one would
ammend documents.
Again, my point is not in favour of this or that policy. Only that a
barebones policy should be documented. So that people know what the
basic rules are, this will allow for realistic expectations with
regards to code being accepted or not in the stable distribution.

More information about the Biopython-dev mailing list