[Bioperl-l] split of Bio::Root from bioperl-live

[Fields, Christopher J]

Again I hate Outlook (they map Ctrl-Enter to ‘Send’).  Let me start again:

The key issue is that a CPAN release of Bio::Root can potentially break any distribution (on CPAN or elsewhere in the so-called ‘DarkPAN’) that has a reliance on Bioperl depending on how they are installed and whether they list their dependencies appropriately.  This can occur when that distribution has a direct requirement for Bio::Root listed in their module dependencies (e.g. installed from CPAN) or if they require pulling in a CPAN module with such a dependency.  
    
The reality is, very few distributions have an actual *direct* requirement for Bio::Root::Root or other modules in that namespace.  They normally build on functionality at a higher level, such as using the parsers (Bio::SeqIO, Bio::AlignIO, Bio::TreeIO), objects describing sequences or features (Bio::Seq, Bio::SeqFeature), etc. and should list those modules specifically as the dependency.  But the traditional (and wrong) way Bioperl had been added is to use Bio::Root::Root as a dependency at some point.  I’m not sure where this started but it seems to have been cargo-culted to a number of places (as I mentioned I saw this in a few GMOD modules, but I have had correspondence from elsewhere).

So, let’s say, if one of those dists then pulls in Bio::Root via it’s dependency list, and Bio::Root is now a separate distribution, and then runs tests using a Bio::SeqIO or other dependency, it will likely fail unless they already have an older BioPerl installed.

So, the solution is (1) we release bioperl with Bio::Root as a separate distributions and then somehow fix every distribution that has the wrong dep listed (impractical, and there is a lot of code that hasn’t been updated in years and would likely be dead), or (2) we fall back to keeping Bio::Root in bioperl-live.  The latter was the simplest solution for an impending release.

So, I *don’t* support releasing Bio::Root separately; it does make logical sense but it has too high a risk of causing more problems than it’s worth, and would impede users updating to the latest releases.

chris

On 8/31/17, 12:34 PM, "Fields, Christopher J" <cjfields at illinois.edu> wrote:

    (Apologies for the top post, I’m forced to use Outlook on Mac and it is incapable of dealing with quoting past emails).
    

    
    
    
    On 8/31/17, 12:10 PM, "carandraug at gmail.com on behalf of Carnë Draug" <carandraug at gmail.com on behalf of carandraug+dev at gmail.com> wrote:
    
        On 31 August 2017 at 17:35, Fields, Christopher J <cjfields at illinois.edu> wrote:
        > On 8/31/17, 7:59 AM, "Bioperl-l on behalf of Carnë Draug" <bioperl-l-bounces+cjfields=illinois.edu at mailman.open-bio.org on behalf of carandraug+dev at gmail.com> wrote:
        >
    …
        >
        > I think the idea was sound in theory, but in practice in caused a
        > number of problems with other tool chains that had incorrect
        > dependencies.
        >
        > I had been getting fairly regular emails about this, primarily
        > off-list, from developers with distributions not on CPAN or on
        > github (not terribly uncommon in our field unfortunately) who would
        > test against bioperl-live and have things break because they needed
        > a Bio::Root installation, which wasn’t on CPAN (it was on github).
        > Also, I found a number of disributions, including a few GMOD tools,
        > that had a Bio::Root::Root dependency listed to pull in BioPerl as a
        > whole, but the *actual* direct dependency was a specific module or
        > interface within Bioperl (say, Bio::DB::SeqFeature or
        > Bio::SeqFeatureI).
        >
        > When the last release (1.7) was being worked on this became more and
        > more apparent as a problem, because a new release with a separate
        > Bio::Root distribution would break these distributions right off the
        > bat, and to fix each of these would require updating all of them to
        > have the correct dependencies.  It became enough of an impediment to
        > an actual 1.7 release that we made a decision to roll this back:
        >
        > https://github.com/bioperl/bioperl-live/issues/114
        >
        > It was announced on the mail list here:
        >
        > https://groups.google.com/d/msg/bioperl-l/fPYyLgN0w2E/GwItrwreAwAJ
        >
        > I do think a stripped-down bioperl-live is a really good idea but it
        > may be best pruning the leaves and not the root, as the vast
        > majority of dependencies are for single modules that see infrequent
        > use on the edges.  So beyond splitting out code that can be
        > functionally independent like Bio::FeatureIO etc I could see having
        > the less-used SeqIO modules with dependencies go either to
        > independent modules on CPAN or to a catch-all ‘bioperl-extras’ or
        > somesuch.
        >
        > chris
        
        If I understood correctly, the issue was that Bio::Root was removed
        from the bioperl-live repo before an alternative was available on
        CPAN.
        
        I could prepare such Bio::Root distribution and then only remove those
        modules from bioperl-live on the day of release.  Would that work?
        
        As a side note, the problems with pruning the leaves and not the root
        is that no one seems to care about them.  This means that no one will
        be extracting them out of bioperl into smaller module distributions.
        
        Carnë