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

[Carnë Draug]

On 2 September 2017 at 22:46, Fields, Christopher J <cjfields at illinois.edu>
wrote:
>     On Sep 1, 2017, at 1:59 PM, Carnë Draug <carandraug+dev at gmail.com>
wrote:
>> [...]
>> 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

That's the thing.  This is not an API change.  The code in all modules
remains the same so their API remains the same.  The only thing that
changes is the name of the distribution that includes each module but
because dependencies in perl are module based, the distribution name
is irrelevant when resolving dependencies.

This is exactly what happened with Bio-Biblio and Bio-EUtilities.

> [...] 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).

Not during the installation, but immediately at runtime.  And I can't
imagine a more helpful error message.  'Can't locate Foo.pm in @INC
(you may need to install the Foo module)'

I still think that this was only a problem before because at the time
there was no distribution with the Bio::Root::* modules.  Anyone at
the stage of seeing that error should know what to do.

>> 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?

Not like that.  See below.

> [...]
> 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 don't think these were successful.  I did Bio::Biblio and helped on
most of the others.  But they are all still dependent on bioperl-live
so little was gained.  Anyone wanting to use or develop them still has
go through the hurdle of installing pretty much all of bioperl.  For
that work to be successful, one of two things need to happen:

  1. the core of bioperl becomes a separate distribution
  2. all the problematic leaves become separate distributions

> 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?

Technical reasons:

These are two separate and independent projects.  You don't need one
to do the other.

Preparing module distributions of smaller sizes is a backwards
incompatible change.  It makes life simpler for users of bioperl.  And
if someone makes backwards incompatible changes to some modules, the
users can still gain from the split since there will be a version of
that distribution with the old API that is simpler to install.

Also, distributions of smaller size will provide a simpler platform
for those with an interest on making those backwards incompatible
changes.

Personal reasons:

Moving modules from one distribution to another is a simpler piece of
work and setting such smaller distributions to make use of dzil is
only a bit more of work.  I can do those on my free time and it serves
my purpose which is to make easier for users to install programs
dependent on bioperl.

On the other hand, those backwards incompatible changes serve me no
purpose so I would just feel frustrated working on them.  Also, I have
no opinion on those backwards incompatible changes.

>> 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.
>
> 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.

Ok.  What is that way?  Is that the split of bioperl leaves?  Because
it's been more than 5 years and doesn't look like anyone is going to
do that.  I agree that causing problems to other projects isn't a
great option but I don't see any other plan.

I offer the work of splitting the core of bioperl modules.  That would
be Bio-Root, Bio-Seq, and Bio-Align distributions independent from the
existing bioperl-live.  I am not so familiar with the whole bioperl
codebase to make a decision what should go into those distributions
though.

> Forgot to add this: could you explicitly list the projects that only
> require Bio::Root?

I was wrong there.  I have since noticed that these do needed other
parts of bioperl beyond Bio::Root.  Those were bio-tools-psort,
bio-tools-psort-svmloc, and bio-graphics.

Carnë
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/bioperl-l/attachments/20170904/a2d029ac/attachment.html>