[Bioperl-l] Splits again

[Sendu Bala]

Nathan S. Haigh wrote:
(Please try and snip more: don't quote whole posts just to reply to 
certain paragraphs)

> Sendu Bala wrote:
>> Chris Fields wrote:
>> When a dev makes a major bugfix to Bio::SeqIO::genbank that all genbank
>> users should have, he could just call './Build dist Bio::SeqIO::genbank'
>> which would generate a new package for Bio::SeqIO::genbank suitable for
>> uploading to CPAN. No more long release cycles and having to constantly
>> tell people to 'use CVS' to get working Bioperl code.
> 
> However, how would the test suite work out with this? e.g. when someone
> installs Bio::SeqIO::genbank they want to have the tests associated with
> Bio::SeqIO::genbank to be run. Would there be tests that would be run
> redundantly if for example someone installed Bio::SeqIO::genbank and
> Bio::SeqIO::fasta?

We would want to move to a strict test-script-per-module system. But 
that's desirable in any case, as it would greatly ease reaching our goal 
of complete test coverage, and subsequent maintenance of those tests.

The genbank test would only run tests specific to genbank parsing, and 
likewise for fasta. They would both have a dependency on Bio::SeqIO, and 
if that was also recently updated, it would get installed prior to you 
installing genbank (and therefor run its own generic SeqIO tests), but 
wouldn't get installed again (wouldn't run its tests again) when you 
install fasta afterwards.


On the subject of tests, I'm reminded of another benefit of the 
individual-module approach. Currently if a test fails during a CPAN 
install, nothing gets installed. Users do one of:

# refuse to install at all (strict sys-admins)
# cry and give up (newbies)
# cry and seek help (newbies who really really need Bioperl)
# force install, leaving them in some undefined state because they 
didn't understand the problems (most remaining users)
# force install, happy that the problems are ok (some Bioperl devs)

With a bundle of individual modules you would install virtually all 
Bioperl modules with no problems, and the problems with the remainder 
would be clear to everyone. No one would need to force install since the 
tests results would now be meaningful: the thing you're trying to 
install really isn't going to work if the tests are failing. If you 
really needed that particular Bioperl module you could then pay 
particular attention to why its failing (most likely some problem with 
an external dependency).


>>> Would they also be individually distributed?  What  would you use to
>>> tie all the individual modules together?
>>
>> They would be tied together by a CPAN bundle. You don't have to
>> 'explain' anything to the CPAN maintainers because you're not doing
>> anything wrong. In fact, you're using it the way you're supposed to.
> 
> Yep. real modules are released as modules, each with their own set of
> dependencies. The use CPAN bundles the way there were supposed to be for
> - - distributing a set of CPAN modules that make a coherent set of
> functionality. You "could" also bundle in other authors modules e.g.
> Bio::ASN1::EntrezGene?

Any bundle featuring Bio::SeqIO::entrezgene would necessarily include 
Bio::ASN1::EntrezGene in the bundle.


> Hmm, how would module versions be handled? Wouldn't this approach
> require each module to have it's own independent version number, which
> could then be used for building the dependencies? Each new release of
> that module would only bump that module's version number.

Yes, that's how it would work. No more global version number.


> Bundles can specify the minimum version of a module to be installed,
> such that bug fixes to individual modules and be released into CPAN and
> would automatically get picked up when installing bundles etc.

Yes.


> I'm not quite sure how the current stable/dev releases would work. I
> assume bug fixes would have to be made on a branch e.g. branch 1.6 and
> released to cpan from there. Then when the next stable release is made,
> all module versions would be bumped and and released to CPAN. With any
> modifications to the content of the bundle to be made. Is it possible to
> have a stable and developer release bundles that are able to specify the
> minimum stable and developer modules versions respectively?

No, the distinction becomes pretty meaningless. We could still do big 
major releases, but modules wouldn't be version-bumped. The big release 
would just be an update of the bundle that specifies the latest version 
of all Bioperl modules.

Remember that bundles only specify the minimum version, not the required 
version: in this brave new world users would end up with the same 
versions of modules if they installed a 1.8 bundle compared to 1.7 bundle.

The only way to get a true snapshot of 1.7 after it was released would 
be if we took snapshots and archived them, making them available from 
bioperl.org (or by checking out the 1.7 tag from cvs/svn).

I don't see that as a significant problem. You lose the trivial benefit 
of being able to install old snapshots from CPAN. The people who have a 
great need to install old snapshots can find their way to bioperl.org no 
problem.