[Biopython-dev] Beta code in the official releases?
Sczesnak, Andrew
Andrew.Sczesnak at med.nyu.edu
Wed Aug 29 13:54:08 EDT 2012
+1
It's been over a year since I first submit my MAF code!
________________________________________
From: biopython-dev-bounces at lists.open-bio.org [biopython-dev-bounces at lists.open-bio.org] on behalf of Brad Chapman [chapmanb at 50mail.com]
Sent: Wednesday, August 22, 2012 8:42 PM
To: Peter Cock; Biopython-Dev Mailing List
Subject: Re: [Biopython-dev] Beta code in the official releases?
Peter;
+1. I'm for making the process of getting new code into
Biopython a bit quicker and this seems like a nice step in that
direction. With code has been well designed tested and documented, this
will help speed the transition into releases and get more eyes on it
quicker, while allowing some potential breaking changes as beta
functionality gets finalized.
Thanks for the good suggestion,
Brad
> Hi all,
>
> One of the ideas I discussed with Bow during this GSoC
> project was introducing a new warning, something like
> Bio.BiopythonBetaCode (the exact name isn't important),
> to be used to label new experimental modules for which
> we *expect* there to be changes in the next release.
>
> The idea is to combine the simplicity of distribution and
> installation of the 'monolithic' Biopython library with some
> of the flexibility offered by a more modular approach.
> This would be particularly helpful for those on Windows,
> where installing a Biopython branch from git is quite a
> daunting task.
>
> The idea is that in one of the next releases you'd be able
> to try Bio.SearchIO (or Bio.Struct or GFF or Variants or ...)
> and see something like this:
>
>>>> from Bio import SearchIO
> Bio/SearchIO/__init__.py:16: BiopythonBetaCode: Bio.SearchIO is in
> beta, and likely to change
> warnings.warn("Bio.SearchIO is in beta, and likely to change",
> BiopythonBetaCode)
>
> By using a specific warning class, any keen beta tester can
> silence all the BiopythonBetaCode warnings if they wished to.
>
> Is anyone familiar enough with Linux packaging polices to
> have any thoughts on how they would treat this? Provided
> we only use this for self contained modules, they could
> potentially split the beta-modules into a sub-package (in the
> same way that Biopython and its BioSQL support are split
> in Debian).
>
> I envision using this as a way to encourage wider 'beta testing'
> of self contained modules which are close to a stable release.
> Does anyone think this is a good idea? Are there any downsides
> I'm overlooking?
>
> Thanks,
>
> Peter
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biopython-dev
_______________________________________________
Biopython-dev mailing list
Biopython-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/biopython-dev
More information about the Biopython-dev
mailing list