split of Bio::Root from bioperl-live

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

split of Bio::Root from bioperl-live

Carnë Draug-2
Hi

Over the years there's been the occasional split of bioperl modules as
separate distributions.  On github, there's the remains of a Bio-Root
which state they are deprecated.

I have been doing some work in Debian package and the bio-root
distribution would be useful.  There's some non bioperl projects that
are only dependent on Bio::Root::* modules but because they are part
of bioperl, that brings in a whole lot of dependencies.

I could prepare a Bio-Root release and sync it with bioperl-live.  But
I was wondering why the split of bio-root was deprecated in the first
place.

As a side note, the split of the rest of bioperl would also be useful,
it's just that it's the split of bio-root that would be most useful
for the packages I have been preparing now.

Thank you
Carnë

_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|

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

Fields, Christopher J
I think the idea was sound in theory, but in practice in caused a number of problems with other tool chains that had incorrect dependencies.  

I had been getting fairly regular emails about this, primarily off-list, from developers with distributions not on CPAN or on github (not terribly uncommon in our field unfortunately) who would test against bioperl-live and have things break because they needed a Bio::Root installation, which wasn’t on CPAN (it was on github).  Also, I found a number of disributions, including a few GMOD tools, that had a Bio::Root::Root dependency listed to pull in BioPerl as a whole, but the *actual* direct dependency was a specific module or interface within Bioperl (say, Bio::DB::SeqFeature or Bio::SeqFeatureI).  

When the last release (1.7) was being worked on this became more and more apparent as a problem, because a new release with a separate Bio::Root distribution would break these distributions right off the bat, and to fix each of these would require updating all of them to have the correct dependencies.  It became enough of an impediment to an actual 1.7 release that we made a decision to roll this back:

https://github.com/bioperl/bioperl-live/issues/114

It was announced on the mail list here:

https://groups.google.com/d/msg/bioperl-l/fPYyLgN0w2E/GwItrwreAwAJ

I do think a stripped-down bioperl-live is a really good idea but it may be best pruning the leaves and not the root, as the vast majority of dependencies are for single modules that see infrequent use on the edges.  So beyond splitting out code that can be functionally independent like Bio::FeatureIO etc I could see having the less-used SeqIO modules with dependencies go either to independent modules on CPAN or to a catch-all ‘bioperl-extras’ or somesuch.

chris

On 8/31/17, 7:59 AM, "Bioperl-l on behalf of Carnë Draug" <bioperl-l-bounces+cjfields=[hidden email] on behalf of [hidden email]> wrote:

    Hi
   
    Over the years there's been the occasional split of bioperl modules as
    separate distributions.  On github, there's the remains of a Bio-Root
    which state they are deprecated.
   
    I have been doing some work in Debian package and the bio-root
    distribution would be useful.  There's some non bioperl projects that
    are only dependent on Bio::Root::* modules but because they are part
    of bioperl, that brings in a whole lot of dependencies.
   
    I could prepare a Bio-Root release and sync it with bioperl-live.  But
    I was wondering why the split of bio-root was deprecated in the first
    place.
   
    As a side note, the split of the rest of bioperl would also be useful,
    it's just that it's the split of bio-root that would be most useful
    for the packages I have been preparing now.
   
    Thank you
    Carnë
   
    _______________________________________________
    Bioperl-l mailing list
    [hidden email]
    http://mailman.open-bio.org/mailman/listinfo/bioperl-l


_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|

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

Carnë Draug-2
On 31 August 2017 at 17:35, Fields, Christopher J <[hidden email]> wrote:

> On 8/31/17, 7:59 AM, "Bioperl-l on behalf of Carnë Draug" <bioperl-l-bounces+cjfields=[hidden email] on behalf of [hidden email]> wrote:
>
>>     Hi
>>
>>     Over the years there's been the occasional split of bioperl modules as
>>     separate distributions.  On github, there's the remains of a Bio-Root
>>     which state they are deprecated.
>>
>>     I have been doing some work in Debian package and the bio-root
>>     distribution would be useful.  There's some non bioperl projects that
>>     are only dependent on Bio::Root::* modules but because they are part
>>     of bioperl, that brings in a whole lot of dependencies.
>>
>>     I could prepare a Bio-Root release and sync it with bioperl-live.  But
>>     I was wondering why the split of bio-root was deprecated in the first
>>     place.
>>
>>     As a side note, the split of the rest of bioperl would also be useful,
>>     it's just that it's the split of bio-root that would be most useful
>>     for the packages I have been preparing now.
>>
>>     Thank you
>>     Carnë
>
> I think the idea was sound in theory, but in practice in caused a
> number of problems with other tool chains that had incorrect
> dependencies.
>
> I had been getting fairly regular emails about this, primarily
> off-list, from developers with distributions not on CPAN or on
> github (not terribly uncommon in our field unfortunately) who would
> test against bioperl-live and have things break because they needed
> a Bio::Root installation, which wasn’t on CPAN (it was on github).
> Also, I found a number of disributions, including a few GMOD tools,
> that had a Bio::Root::Root dependency listed to pull in BioPerl as a
> whole, but the *actual* direct dependency was a specific module or
> interface within Bioperl (say, Bio::DB::SeqFeature or
> Bio::SeqFeatureI).
>
> When the last release (1.7) was being worked on this became more and
> more apparent as a problem, because a new release with a separate
> Bio::Root distribution would break these distributions right off the
> bat, and to fix each of these would require updating all of them to
> have the correct dependencies.  It became enough of an impediment to
> an actual 1.7 release that we made a decision to roll this back:
>
> https://github.com/bioperl/bioperl-live/issues/114
>
> It was announced on the mail list here:
>
> https://groups.google.com/d/msg/bioperl-l/fPYyLgN0w2E/GwItrwreAwAJ
>
> I do think a stripped-down bioperl-live is a really good idea but it
> may be best pruning the leaves and not the root, as the vast
> majority of dependencies are for single modules that see infrequent
> use on the edges.  So beyond splitting out code that can be
> functionally independent like Bio::FeatureIO etc I could see having
> the less-used SeqIO modules with dependencies go either to
> independent modules on CPAN or to a catch-all ‘bioperl-extras’ or
> somesuch.
>
> chris

If I understood correctly, the issue was that Bio::Root was removed
from the bioperl-live repo before an alternative was available on
CPAN.

I could prepare such Bio::Root distribution and then only remove those
modules from bioperl-live on the day of release.  Would that work?

As a side note, the problems with pruning the leaves and not the root
is that no one seems to care about them.  This means that no one will
be extracting them out of bioperl into smaller module distributions.

Carnë

_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|

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

Fields, Christopher J
(Apologies for the top post, I’m forced to use Outlook on Mac and it is incapable of dealing with quoting past emails).

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


So, we either release bioperl with Bio::Root somehow fix every distribution that has the wrong dep listed (not practical), or we fall back to keeping Bio

On 8/31/17, 12:10 PM, "[hidden email] on behalf of Carnë Draug" <[hidden email] on behalf of [hidden email]> wrote:

    On 31 August 2017 at 17:35, Fields, Christopher J <[hidden email]> wrote:
    > On 8/31/17, 7:59 AM, "Bioperl-l on behalf of Carnë Draug" <bioperl-l-bounces+cjfields=[hidden email] on behalf of [hidden email]> wrote:
    >

    >
    > I think the idea was sound in theory, but in practice in caused a
    > number of problems with other tool chains that had incorrect
    > dependencies.
    >
    > I had been getting fairly regular emails about this, primarily
    > off-list, from developers with distributions not on CPAN or on
    > github (not terribly uncommon in our field unfortunately) who would
    > test against bioperl-live and have things break because they needed
    > a Bio::Root installation, which wasn’t on CPAN (it was on github).
    > Also, I found a number of disributions, including a few GMOD tools,
    > that had a Bio::Root::Root dependency listed to pull in BioPerl as a
    > whole, but the *actual* direct dependency was a specific module or
    > interface within Bioperl (say, Bio::DB::SeqFeature or
    > Bio::SeqFeatureI).
    >
    > When the last release (1.7) was being worked on this became more and
    > more apparent as a problem, because a new release with a separate
    > Bio::Root distribution would break these distributions right off the
    > bat, and to fix each of these would require updating all of them to
    > have the correct dependencies.  It became enough of an impediment to
    > an actual 1.7 release that we made a decision to roll this back:
    >
    > https://github.com/bioperl/bioperl-live/issues/114
    >
    > It was announced on the mail list here:
    >
    > https://groups.google.com/d/msg/bioperl-l/fPYyLgN0w2E/GwItrwreAwAJ
    >
    > I do think a stripped-down bioperl-live is a really good idea but it
    > may be best pruning the leaves and not the root, as the vast
    > majority of dependencies are for single modules that see infrequent
    > use on the edges.  So beyond splitting out code that can be
    > functionally independent like Bio::FeatureIO etc I could see having
    > the less-used SeqIO modules with dependencies go either to
    > independent modules on CPAN or to a catch-all ‘bioperl-extras’ or
    > somesuch.
    >
    > chris
   
    If I understood correctly, the issue was that Bio::Root was removed
    from the bioperl-live repo before an alternative was available on
    CPAN.
   
    I could prepare such Bio::Root distribution and then only remove those
    modules from bioperl-live on the day of release.  Would that work?
   
    As a side note, the problems with pruning the leaves and not the root
    is that no one seems to care about them.  This means that no one will
    be extracting them out of bioperl into smaller module distributions.
   
    Carnë





_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|

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

Fields, Christopher J
Again I hate Outlook (they map Ctrl-Enter to ‘Send’).  Let me start again:

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

On 8/31/17, 12:34 PM, "Fields, Christopher J" <[hidden email]> wrote:

    (Apologies for the top post, I’m forced to use Outlook on Mac and it is incapable of dealing with quoting past emails).
   

   
   
   
    On 8/31/17, 12:10 PM, "[hidden email] on behalf of Carnë Draug" <[hidden email] on behalf of [hidden email]> wrote:
   
        On 31 August 2017 at 17:35, Fields, Christopher J <[hidden email]> wrote:
        > On 8/31/17, 7:59 AM, "Bioperl-l on behalf of Carnë Draug" <bioperl-l-bounces+cjfields=[hidden email] on behalf of [hidden email]> wrote:
        >
    …
        >
        > I think the idea was sound in theory, but in practice in caused a
        > number of problems with other tool chains that had incorrect
        > dependencies.
        >
        > I had been getting fairly regular emails about this, primarily
        > off-list, from developers with distributions not on CPAN or on
        > github (not terribly uncommon in our field unfortunately) who would
        > test against bioperl-live and have things break because they needed
        > a Bio::Root installation, which wasn’t on CPAN (it was on github).
        > Also, I found a number of disributions, including a few GMOD tools,
        > that had a Bio::Root::Root dependency listed to pull in BioPerl as a
        > whole, but the *actual* direct dependency was a specific module or
        > interface within Bioperl (say, Bio::DB::SeqFeature or
        > Bio::SeqFeatureI).
        >
        > When the last release (1.7) was being worked on this became more and
        > more apparent as a problem, because a new release with a separate
        > Bio::Root distribution would break these distributions right off the
        > bat, and to fix each of these would require updating all of them to
        > have the correct dependencies.  It became enough of an impediment to
        > an actual 1.7 release that we made a decision to roll this back:
        >
        > https://github.com/bioperl/bioperl-live/issues/114
        >
        > It was announced on the mail list here:
        >
        > https://groups.google.com/d/msg/bioperl-l/fPYyLgN0w2E/GwItrwreAwAJ
        >
        > I do think a stripped-down bioperl-live is a really good idea but it
        > may be best pruning the leaves and not the root, as the vast
        > majority of dependencies are for single modules that see infrequent
        > use on the edges.  So beyond splitting out code that can be
        > functionally independent like Bio::FeatureIO etc I could see having
        > the less-used SeqIO modules with dependencies go either to
        > independent modules on CPAN or to a catch-all ‘bioperl-extras’ or
        > somesuch.
        >
        > chris
       
        If I understood correctly, the issue was that Bio::Root was removed
        from the bioperl-live repo before an alternative was available on
        CPAN.
       
        I could prepare such Bio::Root distribution and then only remove those
        modules from bioperl-live on the day of release.  Would that work?
       
        As a side note, the problems with pruning the leaves and not the root
        is that no one seems to care about them.  This means that no one will
        be extracting them out of bioperl into smaller module distributions.
       
        Carnë
   
   
   
   
   


_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|

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

Carnë Draug-2
On 31 August 2017 at 18:45, Fields, Christopher J <[hidden email]> 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ë

_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|

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

Fields, Christopher J

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

On 31 August 2017 at 18:45, Fields, Christopher J <[hidden email]> 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
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|

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

Fields, Christopher J
...
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

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

chris

_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|

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

Carnë Draug-2
In reply to this post by Fields, Christopher J
On 2 September 2017 at 22:46, Fields, Christopher J <[hidden email]> wrote:
>     On Sep 1, 2017, at 1:59 PM, Carnë Draug <[hidden email]> 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ë

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