[Bioperl-l] BioPerl 1.6 RC1

Fri Jan 2 15:15:37 EST 2009

I asked Lincoln about this but hadn't received a reply; oddly, I  
removed scripts/biographics and examples/biographics from trunk but  
the merge didn't remove them from the branch.  They won't be in RC2  
(Sun-Mon).

chris

On Dec 30, 2008, at 12:48 PM, Scott Cain wrote:

> Hi,
>
> For the scripts currently in BioPerl core that use BioGraphics, do we
> think that they should no longer be distributed with BioPerl but
> should instead be moved to the BioGraphics distribution?  I imagine
> someone trying to use bp_embl2picture.pl and being surprised that it
> doesn't work.
>
> Thoughts?
>
> Scott
>
>
> On Tue, Dec 30, 2008 at 11:16 AM, Christopher Fields
> <cjfields at illinois.edu> wrote:
>> 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)
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>
>
>
>
> -- 
> ------------------------------------------------------------------------
> Scott Cain, Ph. D.                                   scott at  
> scottcain dot net
> GMOD Coordinator (http://gmod.org/)                     216-392-3087
> Ontario Institute for Cancer Research
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l