[Bioperl-l] Splits again
bix at sendu.me.uk
Thu Jun 28 05:11:39 EDT 2007
Nathan S. Haigh wrote:
(Please try and snip more: don't quote whole posts just to reply to
> 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
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.
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.
> 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
More information about the Bioperl-l