[Bioperl-l] BioPerl 1.6 RC1

[Christopher Fields]

All,

I can't respond adequately until I return from vacation; I'm  responding from a dial-up line in Texas (?!?) so responding to each message in kind will take a year or two (I did mention that I would be away from Dec 26-31, but it looks like that will be until Jan 1).  


---- Original message ----
>Date: Tue, 30 Dec 2008 02:31:43 +0000
>From: Sendu Bala <bix at sendu.me.uk>  
>Subject: Re: [Bioperl-l] BioPerl 1.6 RC1  
>To: Alex Lancaster <alexl at users.sourceforge.net>
>Cc: bioperl-l at lists.open-bio.org, Chris Fields <cjfields at illinois.edu>
>
>Alex Lancaster wrote:
>>>>>>>>> "SB" == Sendu Bala writes:
>> Also can you clarify the expected name of the tarball, is it bioperl,
>> or BioPerl?  The 1.5.2 release used bioperl-1.5.2_102.tar.bz2 whereas
>> 1.5.9._1 uses BioPerl-1.5.9._1.tar.bz2 and it would be good if there
>> was consistency as it really helps from maintaining the packages and
>> generating links etc.
>
>Naming consistency is built into the system.
>./Build dist
>generates a file named:
>bioperl-1.5.9_1.tar.bz2
>
>I guess Chris decided to rename the file before uploading, and its up to 
>him what future files are named, but I second your suggestion this 
>should be consistent.

The package is named after the toolkit (BioPerl vs bioperl).  We can revert back to simply 'bioperl', but since we keep referring to the package as 'BioPerl' on the wiki and elsewhere we should use that for the CPAN from this point on.  

>Chris: I note that extraneous files like 'test.txt' and others made it 
>into the RC1 .tar.gz you uploaded. What I always did was a clean export 
>of the tag and built from there. BTW, the dist action also warns you 
>about modules with their own version: Bio::DB::GFF::Aggregator::orf in 
>this case. You might want to investigate that.

I noticed that it's packaging up everything in the local directory, yes (that was after the upload unfortunately).  That'll be fixed for RC2; I'll look for a more amenable fix when I get back (a packlist of files would work around this, but I'm not sure how well that will work with a large distro like BioPerl).

>> SB> There would most likely be a single CPAN bundle specifying all the
>> SB> different BioPerl packages but without any version number
>> SB> specifications. When a user installs the bundle it would install
>> SB> the latest version of each package.
>> 
>> SB> Each individual sub-package, on the other hand, would specify the
>> SB> version of any other sub-packages or core that it depends on.
>> 
>> OK, right.  So if any of the sub-packages were incremented
>> independently, would a new bundle be generated, or would new bundles
>> only be updated for major releases?  Hmm, I'm not sure if subpackages
>> with different version numbers from the main package can be generated
>> from a single SRPM, so that might be a bit tricky.  But if core is
>> only a small number of CPAN pakcages, that might not be so bad,
>> although it would mean having to go through review for each of the
>> (new) CPAN modules and more maintainance, so it might be a while
>> before it would be in Fedora.  When is this scheduled to happen?
>> (post-1.6, I hope!)
>
>'core' will only ever be one CPAN package (one tarball).
>A new bundle would not be generated when a sub-package is incremented. 
>The whole point of sub-packages is that they're independent and can be 
>developed and released without affecting core or the other sub-packages.
>
>The only reason for a bundle update would be to add more new 
>sub-packages to it.
>
>Again, how does Fedora currently emulate CPAN Bundles?
>
>
>Just so we're not getting our wires crossed, in this context 'core' 
>would be BioPerl-1.5.9._1.tar.bz2 and 6 examples of sub-packages would 
>be the .tar.bz2 distribution files for Bio::Graphics, 
>Bio::ASN1::EntrezGene, BioPerl-run, BioPerl-db, BioPerl-network and 
>BioPerl-ext.
>
>The kind of thing that could then happen in the future is that (to take 
>some random imaginary examples) BioPerl-1.7.0.tar.bz2 is released as 
>'core' which is a bit smaller than BioPerl-1.5.9._1.tar.bz2 because 
>Bio::Structure is missing from it, and there is a new independent 
>sub-package released for Bio::Structure, just like what happened with 
>Bio::Graphics.
>
>
>>> "Requires: perl(Bio::Graphics)"
>> 
>> RPM has a script with heuristics that search .pm and .pl files for
>> 'use <module-name>' type constructs to automatically generate
>> 'Requires", that sometimes guess wrong.  To check, I grepped an
>> exploded package for instances of 'Bio::Graphics' and what returned is
>> below, at the end of the e-mail.  I suspect that the 'use
>> Bio::Graphics' in some of the installed scripts in bin/ such as
>> bp_glyphs2-demo.pl are causing the issue.  Shouldn't these scripts
>> perhaps be moved to the Bio::Graphics CPAN module (along with the
>> scripts in examples/)?
>
>Thanks for pointing that out. I'll leave it to Chris to sort that out...

Yes, those scripts should be moved over (already have indicated this to Lincoln).  I can't check my local svn co (it's sitting about ~1000 miles away from me in a closet right now).  

>> If the Bio::Graphics is truly not needed, for the moment it is
>> possible to also override and filter out the bogus Requires until such
>> time as these scripts are moved to the appropriate place.
>
>Great, go ahead and do that if you like.

I'm not quite sure why we are attempting to RPM package up a release candidate unless it's strictly for the purposes of testing things out.  I anticipate the final 1.6 will be out in short period of time (within a few weeks).  Maybe this has already been answered, just haven't had time to read back along the thread yet.

Anyway, patience everyone.  This is an RC not a final release, and I anticipated that a few things would probably be screwy.  It appears only a few things need to be addressed and cleaned up prior to a final release, so overall RC1 did what I wanted (including uncovering an odd PAML bug according to CPAN Testers).

-c (from the backwoods in Texas)