Re: Proposition for Biopython 2

Hi!

Yes, in fact, the image on the Wikipedia page inspired me in the logo 
design.

Best regards

Patrick


On 24.11.2017 16:43, Peter Cock wrote:
> 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