Re: BioPerl 1.6 RC1

Lincoln,

There were several scripts and examples in bioperl-live which have  
been removed but somehow persisted in the branch and were in 1.6 RC1  
(a test also remained which was also removed, t/Graphics/ 
Pictogram.t).  I didn't know if you wanted these moved to Sourceforge;  
I saw there were several examples already in the Bio::Graphics  
repository.

There were a few other modules in Bio::Graphics namespace moved over  
to Sourceforge that I wasn't sure whether you wanted to maintain, such  
as DrawTransmembrane.pm and Pictogram.pm.  If needed we can resurrect  
them in trunk, under either Bio::Graphics or a different namespace  
(latter is probably better, any suggestions?).  They don't appear to  
rely on other Bio::Graphics modules directly.

chris

On Jan 3, 2009, at 9:51 AM, Lincoln Stein wrote:

> Sorry, what's the question? Anything having to do with biographics  
> should be
> removed as it now has its own separately installable CPAN module.
>
> Lincoln
>
> On Fri, Jan 2, 2009 at 3:15 PM, Chris Fields <cjfields <at> illinois.edu>  
> wrote:
>
>> 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
>>>
>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l <at> lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>
>
>
>
> -- 
> Lincoln D. Stein
>
> Ontario Institute for Cancer Research
> 101 College St., Suite 800
> Toronto, ON, Canada M5G0A3
> 416 673-8514
> Assistant: Renata Musa <Renata.Musa <at> oicr.on.ca>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l <at> lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l