<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Sep 1, 2017, at 1:59 PM, Carnë Draug <<a href="mailto:carandraug+dev@gmail.com" class="">carandraug+dev@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On 31 August 2017 at 18:45, Fields, Christopher J <<a href="mailto:cjfields@illinois.edu" class="">cjfields@illinois.edu</a>> wrote:<br class="">
<blockquote type="cite" class=""><br class="">
The key issue is that a CPAN release of Bio::Root can potentially<br class="">
break any distribution (on CPAN or elsewhere in the so-called<br class="">
‘DarkPAN’) that has a reliance on Bioperl depending on how they are<br class="">
installed and whether they list their dependencies appropriately.<br class="">
This can occur when that distribution has a direct requirement for<br class="">
Bio::Root listed in their module dependencies (e.g. installed from<br class="">
CPAN) or if they require pulling in a CPAN module with such a<br class="">
dependency.<br class="">
<br class="">
The reality is, very few distributions have an actual *direct*<br class="">
requirement for Bio::Root::Root or other modules in that namespace.<br class="">
They normally build on functionality at a higher level, such as<br class="">
using the parsers (Bio::SeqIO, Bio::AlignIO, Bio::TreeIO), objects<br class="">
describing sequences or features (Bio::Seq, Bio::SeqFeature),<br class="">
etc. and should list those modules specifically as the dependency.<br class="">
But the traditional (and wrong) way Bioperl had been added is to use<br class="">
Bio::Root::Root as a dependency at some point. I’m not sure where<br class="">
this started but it seems to have been cargo-culted to a number of<br class="">
places (as I mentioned I saw this in a few GMOD modules, but I have<br class="">
had correspondence from elsewhere).<br class="">
<br class="">
So, let’s say, if one of those dists then pulls in Bio::Root via<br class="">
it’s dependency list, and Bio::Root is now a separate distribution,<br class="">
and then runs tests using a Bio::SeqIO or other dependency, it will<br class="">
likely fail unless they already have an older BioPerl installed.<br class="">
<br class="">
So, the solution is (1) we release bioperl with Bio::Root as a<br class="">
separate distributions and then somehow fix every distribution that<br class="">
has the wrong dep listed (impractical, and there is a lot of code<br class="">
that hasn’t been updated in years and would likely be dead), or (2)<br class="">
we fall back to keeping Bio::Root in bioperl-live. The latter was<br class="">
the simplest solution for an impending release.<br class="">
<br class="">
So, I *don’t* support releasing Bio::Root separately; it does make<br class="">
logical sense but it has too high a risk of causing more problems<br class="">
than it’s worth, and would impede users updating to the latest<br class="">
releases.<br class="">
<br class="">
chris<br class="">
</blockquote>
<br class="">
So the use-cases preventing the split of Bio::Root into a separate<br class="">
distribution are projects with incorrectly listed dependencies?<br class="">
That's their problem to solve. It's their bug.</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>Any thoughts or work towards that goal would help, but see below on my thoughts if you want a cleaner bioperl.</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="">What will happen if one day we simply remove Bio::Root::Root because<br class="">
it's just not necessary any more? Or what if the modules they really<br class="">
depend on, say Bio::AlignIO, are made into a separate distribution but<br class="">
they are only dependent on Bio::Root::Root?<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>If that is the intent, I’d argue for an explicitly <b class=""><i class="">non-</i></b>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. </div>
<div><br class="">
</div>
<div>Do you want to take this on?</div>
<div> </div>
<blockquote type="cite" class="">
<div class="">
<div class="">I won't do it without your support obviously, but not doing this<br class="">
prevents the split of bioperl. This is because if we can't extract<br class="">
the root of bioperl, then we need to extract the leaves. However, no<br class="">
one seems willing to do that. Also, I believe it has already been<br class="">
agreed that a monolithic bioperl package is damaging to the bioperl<br class="">
project, it makes it harder for both users and developers.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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. </div>
<div><br class="">
</div>
<div>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?</div>
<div><br class="">
</div>
<div>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.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">Following that logic, not splitting the core is damaging the project.<br class="">
And now that damage is being caused to prevent damage to dependent<br class="">
projects who couldn't be arsed with listing their dependencies<br class="">
correctly in the first place.<br class="">
<br class="">
Carnë<br class="">
</div>
</div>
</blockquote>
<br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>chris</div>
<br class="">
</div>
</div>
</body>
</html>