[Bioperl-l] split of Bio::Root from bioperl-live
Fields, Christopher J
cjfields at illinois.edu
Thu Aug 31 17:34:58 UTC 2017
(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, "carandraug at gmail.com on behalf of Carnë Draug" <carandraug at gmail.com on behalf of carandraug+dev at gmail.com> wrote:
On 31 August 2017 at 17:35, Fields, Christopher J <cjfields at illinois.edu> wrote:
> On 8/31/17, 7:59 AM, "Bioperl-l on behalf of Carnë Draug" <bioperl-l-bounces+cjfields=illinois.edu at mailman.open-bio.org on behalf of carandraug+dev at gmail.com> 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ë
More information about the Bioperl-l
mailing list