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

[Carnë Draug]

On 31 August 2017 at 18:45, Fields, Christopher J <cjfields at illinois.edu> 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.

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?

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.

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ë