<div dir="ltr">On 2 September 2017 at 22:46, Fields, Christopher J <<a href="mailto:cjfields@illinois.edu">cjfields@illinois.edu</a>> wrote:<br>>     On Sep 1, 2017, at 1:59 PM, Carnë Draug <<a href="mailto:carandraug%2Bdev@gmail.com">carandraug+dev@gmail.com</a>> wrote:<br>>> [...]<br>>> So the use-cases preventing the split of Bio::Root into a separate<br>>> distribution are projects with incorrectly listed dependencies?<br>>> That's their problem to solve.  It's their bug.<br>><br>> It’s a sudden and significant API change<br><br>That's the thing.  This is not an API change.  The code in all modules<br>remains the same so their API remains the same.  The only thing that<br>changes is the name of the distribution that includes each module but<br>because dependencies in perl are module based, the distribution name<br>is irrelevant when resolving dependencies.<br><br>This is exactly what happened with Bio-Biblio and Bio-EUtilities.<br><br>> [...] I’m not sure how we would let<br>> someone know their dependency is wrong during installation, beyond<br>> complete breakage (which to me isn’t a great option).<br><br>Not during the installation, but immediately at runtime.  And I can't<br>imagine a more helpful error message.  'Can't locate Foo.pm in @INC<br>(you may need to install the Foo module)'<br><br>I still think that this was only a problem before because at the time<br>there was no distribution with the Bio::Root::* modules.  Anyone at<br>the stage of seeing that error should know what to do.<br><br>>> What will happen if one day we simply remove Bio::Root::Root<br>>> because it's just not necessary any more?  Or what if the modules<br>>> they really depend on, say Bio::AlignIO, are made into a separate<br>>> distribution but they are only dependent on Bio::Root::Root?<br>><br>> If that is the intent, I’d argue for an explicitly<br>> non-backwards-compatible release, incorporating changes which we<br>> worried about in the past, with a version bump to BioPerl v2.0.<br>> Personally, I think this is a grand idea, but not something I have<br>> time to lead, though I can certainly discuss and help.<br>><br>> Do you want to take this on?<br><br>Not like that.  See below.<br><br>> [...]<br>> Also note we have successfully split out Bio::Graphics,<br>> Bio::Coordinate, Bio::Biblio, Bio::FeatureIO, and Bio::EUtilities,<br>> there are many examples of this being done successfully.<br><br>I don't think these were successful.  I did Bio::Biblio and helped on<br>most of the others.  But they are all still dependent on bioperl-live<br>so little was gained.  Anyone wanting to use or develop them still has<br>go through the hurdle of installing pretty much all of bioperl.  For<br>that work to be successful, one of two things need to happen:<br><br>  1. the core of bioperl becomes a separate distribution<br>  2. all the problematic leaves become separate distributions<br><br>> I was also<br>> initially on board with a Bio::Root split, but it simply wasn’t<br>> practical (timing or otherwise) for a 1.7 release, and I think if<br>> you’re going that route why not just go for a clean slate and v2.0<br>> as mentioned above?<br><br>Technical reasons:<br><br>These are two separate and independent projects.  You don't need one<br>to do the other.<br><br>Preparing module distributions of smaller sizes is a backwards<br>incompatible change.  It makes life simpler for users of bioperl.  And<br>if someone makes backwards incompatible changes to some modules, the<br>users can still gain from the split since there will be a version of<br>that distribution with the old API that is simpler to install.<br><br>Also, distributions of smaller size will provide a simpler platform<br>for those with an interest on making those backwards incompatible<br>changes.<br><br>Personal reasons:<br><br>Moving modules from one distribution to another is a simpler piece of<br>work and setting such smaller distributions to make use of dzil is<br>only a bit more of work.  I can do those on my free time and it serves<br>my purpose which is to make easier for users to install programs<br>dependent on bioperl.<br><br>On the other hand, those backwards incompatible changes serve me no<br>purpose so I would just feel frustrated working on them.  Also, I have<br>no opinion on those backwards incompatible changes.<br><br>>> Following that logic, not splitting the core is damaging the<br>>> project.  And now that damage is being caused to prevent damage to<br>>> dependent projects who couldn't be arsed with listing their<br>>> dependencies correctly in the first place.<br>><br>> I’m not disagreeing with you, but there are better ways that to<br>> simply break backwards compatibility w/o warning, even if those<br>> dependent projects are the ones with the bug.<br><br>Ok.  What is that way?  Is that the split of bioperl leaves?  Because<br>it's been more than 5 years and doesn't look like anyone is going to<br>do that.  I agree that causing problems to other projects isn't a<br>great option but I don't see any other plan.<br><br>I offer the work of splitting the core of bioperl modules.  That would<br>be Bio-Root, Bio-Seq, and Bio-Align distributions independent from the<br>existing bioperl-live.  I am not so familiar with the whole bioperl<br>codebase to make a decision what should go into those distributions<br>though.<br><br>> Forgot to add this: could you explicitly list the projects that only<br>> require Bio::Root?<br><br>I was wrong there.  I have since noticed that these do needed other<br>parts of bioperl beyond Bio::Root.  Those were bio-tools-psort,<br>bio-tools-psort-svmloc, and bio-graphics.<br><br>Carnë</div>