Re: split of Bio::Root from bioperl-live

On Sep 1, 2017, at 1:59 PM, Carnë Draug <[email protected]<mailto:[email protected]>> wrote:

On 31 August 2017 at 18:45, Fields, Christopher J <[email protected]<mailto:[email protected]>> wrote:

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

So the use-cases preventing the split of Bio::Root into a separate
distribution are projects with incorrectly listed dependencies?
That's their problem to solve.  It's their bug.

It’s a sudden and significant API change, so some form of a warning would be helpful to push them in the right direction.  We unfortunately don’t have an easy way to let them know, e.g. noisy annoying deprecation warnings are very useful for this and help for making significant changes, such as warning a module or method is deprecated. I’m not sure how we would let someone know their dependency is wrong during installation, beyond complete breakage (which to me isn’t a great option).  Unfortunately it seems mailing lists these days aren’t nearly as effective in announcing such changes.

Any thoughts or work towards that goal would help, but see below on my thoughts if you want a cleaner bioperl.

What will happen if one day we simply remove Bio::Root::Root because
it's just not necessary any more?  Or what if the modules they really
depend on, say Bio::AlignIO, are made into a separate distribution but
they are only dependent on Bio::Root::Root?

If that is the intent, I’d argue for an explicitly non-backwards-compatible release, incorporating changes which we worried about in the past, with a version bump to BioPerl v2.0.  Personally, I think this is a grand idea, but not something I have time to lead, though I can certainly discuss and help.

Do you want to take this on?

I won't do it without your support obviously, but not doing this
prevents the split of bioperl.  This is because if we can't extract
the root of bioperl, then we need to extract the leaves.  However, no
one seems willing to do that.  Also, I believe it has already been
agreed that a monolithic bioperl package is damaging to the bioperl
project, it makes it harder for both users and developers.

If my last post wasn’t clear (and if my past history with bioperl hasn’t indicated this already), I’m perfectly on-board with splitting out the leaves, particularly the ones with onerous outside dependencies or the little-used code.  The idea originated with Sendu Bala and myself a while back, and though we had our disagreements on the overall approach we both agreed on that point.

Also note we have successfully split out Bio::Graphics, Bio::Coordinate, Bio::Biblio, Bio::FeatureIO, and Bio::EUtilities, there are many examples of this being done successfully.  I was also initially on board with a Bio::Root split, but it simply wasn’t practical (timing or otherwise) for a 1.7 release, and I think if you’re going that route why not just go for a clean slate and v2.0 as mentioned above?

As for the current code I’m not stopping anyone who wants to get the ball rolling; I just have a lot of other obligations and much less time than I used to have, hence the lack of momentum on this.

Following that logic, not splitting the core is damaging the project.
And now that damage is being caused to prevent damage to dependent
projects who couldn't be arsed with listing their dependencies
correctly in the first place.

Carnë

I’m not disagreeing with you, but there are better ways that to simply break backwards compatibility w/o warning, even if those dependent projects are the ones with the bug.

chris

_______________________________________________
Bioperl-l mailing list
[email protected]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l