[Biopython] Planning Biopython 1.72

[Michiel de Hoon]

 Hi Peter,
I see. We could put a try: except: block around importing _aligners, and raise an Exception if anybody tries to instantiate a PairwiseAligner if the C code is not available.I am against putting the pairwise aligner code in a separate submodule since, according to the Zen of Python, flat is better than nested.

Best,-Michiel

    On Saturday, June 23, 2018, 6:47:39 PM GMT+9, Peter Cock <p.j.a.cock at googlemail.com> wrote:  
 
 On Sat, Jun 23, 2018 at 2:32 AM, Michiel de Hoon <mjldehoon at yahoo.com> wrote:
>> That has made be realise that the new pairwise alignment
> code being in Bio.Align at top level means it gets imported
> as a side effect all over the place. With hindsight, it would
> have been better as a sub-module to avoid this overhead.
> What are people's thoughts here?
>
> Hi Peter,
> Can you show an example where this happens? I guess
> usually people would use "from Bio import Align"; then it
> doesn't really matter.
>
> Best,
> -Michiel

Using AlignIO imports Align, which now includes the new C code.
This means if there is a problem with the C code, lots of things
break (including SeqIO too, which imports AlignIO when needed).

For an example, look at the logs for this attempt at building
Linux and macOS wheels for Biopython 1.72,

https://travis-ci.org/biopython/biopython-wheels/builds/395533386

It seems to be something silly with the paths, meaning none
of the C code is available from the installed new wheel.

I was not able to solve this last night (although the Windows
wheels are fine, which are built on AppVeyor instead).

Peter
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biopython/attachments/20180624/06021e49/attachment.html>