Re: Proposition for Biopython 2

Thanks Patrick,

This has not been a good month for Biopython emails - on top of the
mailman problems, your second email was wrongly marked as spam
by Google, so again a long delay before I saw it. Sigh.

That seems to be a practical way forward, and the proposed licensing
is a good choice for any future code exchange. We need to put more
effort into Biopython's transition to the BSD license.

Peter

P.S. I like the BioTite logo, is it a crystal reflecting one meaning of
biotite as a mica mineral? https://en.wikipedia.org/wiki/Biotite


On Wed, Nov 15, 2017 at 8:40 AM, Patrick Kunzmann
<[email protected]> wrote:
> Dear Biopython community,
>
> I decided to put the proposed Biopython 2 code base into an separate project
> for the time being. The main reason for this are the clarity issues that
> have bothered me lately: Although distinguishing Biopython and the proposed
> Biopython 2 would be easy on GitHub (different repos) and relatively easy on
> PyPI (version identifier), I think confusions could occur in other contexts
> (e.g. in the mailing list or StackOverflow). Therefore, the project is
> continued unter the name 'Biotite'. The repository was moved into a separate
> GitHub organisation and can be found at
> https://github.com/biotite-dev/biotite . The project is still licensed under
> BSD 3-clause so potentially a project merge is still possible at a later
> point.
>
> Best regards,
> Patrick
>
>
> On 02.11.2017 11:42, Patrick Kunzmann wrote:
>>
>> Dear Biopython community,
>>
>> here I present you a proposition for a potential Biopython 2.x code base.
>> But first things first:
>>
>> A few months ago I proposed an endeavor to rewrite Biopython in order to
>> bring it onto modern scientific Python standards
>> (http://lists.open-bio.org/pipermail/biopython-dev/2017-June/021740.html).
>> Arguably, the consensus was that this is something that should be done, but
>> those changes would require almost a complete rewrite and barely anyone has
>> time for it. Therefore, I took the initiative some time later and created an
>> experimental repository for creating actual Biopython 2 code
>> (https://github.com/padix-key/biopython2experimental). Unfortunately it
>> seems that the announcement mail for that did not reach the mailing list,
>> but went missing in the deep of the web. Anyway, the repository is now at a
>> presentable state. The corresponding HTML documentation (including tutorial,
>> API reference and install instructions) can be found under
>> https://github.com/padix-key/biopython2/files/1437242/doc.zip . So far it is
>> not possible to install the package from PyPI, since it is not the offical
>> Biopython 2 package. Instead you have to install it directly from the repo,
>> if you want to test the package.
>>
>> The package contains basic types and operations for working with structure
>> and sequence data, offers biological database interaction with RCSB and NCBI
>> Entrez and provides seamless interfaces to external software. Although the
>> package aims to achieve similar area of application as Biopython 1.x, it is
>> a complete rewrite.
>>
>> The package is still in early development. I tried to incorporate the
>> ideas you and I brought up in the Biopython 2 discussion and still
>> everything is subject to changes in the discussion with you. I already have
>> some questions for discussion:
>>
>> 1. Should this package still be dual licensed? Since the BSD 3-Clause and
>> the Biopython license are quite similar, I would suggest licensing Biopython
>> 2 only under BSD 3-Clause for clarity. But I do not have a strong opinion on
>> that.
>>
>> 2. In our previous discussion some of you proposed putting only core
>> functionality into Biopython 2 and leaving specialized code installable as
>> plugins. This package does not contain a mechanism for plugin packages, yet.
>> I would rather suggest a 'recommended packages' approach: Code that is based
>> on Biopython 2 and tackles a general biological problem would be linked in a
>> 'Recommended packages' section of the Biopython 2 documentation. In my
>> opinion, direct plugins in the Biopython 2 package requires some confusing
>> namespace wizardry. Recommended packages would achieve almost the same, with
>> the slight difference, that the user writes 'import recommendedpackage'
>> rather than 'import biopython.someplugin'.
>>
>> If this package is accepted by the community, I would like to hand over
>> repository ownership to the 'Biopython' organisation on GitHub and I would
>> like to continue and supervise its development as part of the GitHub
>> 'Biopython' organisation.
>>
>> Best regards,
>> Patrick Kunzmann
>>
>
> _______________________________________________
> Biopython-dev mailing list
> [email protected]
> http://mailman.open-bio.org/mailman/listinfo/biopython-dev