[Bioperl-l] Splits again
cjfields at uiuc.edu
Sat Jun 30 22:46:05 EDT 2007
On Jun 30, 2007, at 4:32 PM, Sendu Bala wrote:
> Hilmar Lapp wrote:
>> On Jun 28, 2007, at 3:19 PM, Sendu Bala wrote:
>>> Very definitely the latter. The key benefit of my approach is
>>> that the organisation stays as is and that a snapshot of the
>>> repository remains a single directory of modules in Bio so that
>>> people don't have to 'install' Bioperl, they can still just
>>> uncompress the archive (or check out the package from svn) and
>>> point their PERL5LIB to the root dir of the package.
>> In this sense, I understand a release pumpkin will generate ~900
>> packages to upload to CPAN? How much hassle is that compared to
>> what uploading a bioperl release means right now?
> I'd have to investigate. I did my uploads using the PAUSE website,
> which for 900 packages would be unfeasible. Will have to see if the
> process can be automated.
Not that they would care one way or another but maybe we should
contact the CPAN maintainers to get their thoughts. They might have
>> How brittle is all the Build.PL code that will be needed to
>> automate all of this, and how difficult will it be to maintain?
>> For example, if someone adds in 10 new modules, what Build.PL-
>> related work will need to be done?
> Well, my plan will be that once the work is done, you won't need to
> touch the Build.PL code again. My intent is that the pumpkin can
> just type one command and not think about anything.
> As for the reality, I won't know until I think about it properly
> and experiment.
A good experiment for a branch. I still think this could be
accomplished step-wise; for instance run a quick test using something
with a simple dependency tree like Bio::Root::Root (only needs
RootI), finish up with Bio::Root*, then work down into PrimarySeq,
Seq, etc. Submit them to CPAN piecemeal or in batches (all
Bio::Seq*, so on).
If the Build.PL, etc are to be generated on the fly then maybe there
should be a simple way of registering or matching tests to modules
(or vice versa) to ease the pain, particularly for new code.
More information about the Bioperl-l