[Bioperl-l] BioPerl 1.6 RC1
cjfields at illinois.edu
Fri Jan 2 20:15:37 UTC 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
On Dec 30, 2008, at 12:48 PM, Scott Cain wrote:
> 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.
> On Tue, Dec 30, 2008 at 11:16 AM, Christopher Fields
> <cjfields at illinois.edu> wrote:
>> 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
>>>> or BioPerl? The 1.5.2 release used bioperl-1.5.2_102.tar.bz2
>>>> 1.5.9._1 uses BioPerl-1.5.9._1.tar.bz2 and it would be good if
>>>> was consistency as it really helps from maintaining the packages
>>>> generating links etc.
>>> Naming consistency is built into the system.
>>> ./Build dist
>>> generates a file named:
>>> 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
>>> 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
>>>> SB> the latest version of each package.
>>>> SB> Each individual sub-package, on the other hand, would specify
>>>> 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
>>>> only be updated for major releases? Hmm, I'm not sure if
>>>> with different version numbers from the main package can be
>>>> 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
>>> The whole point of sub-packages is that they're independent and
>>> can be
>>> developed and released without affecting core or the other sub-
>>> 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
>>> be the .tar.bz2 distribution files for Bio::Graphics,
>>> Bio::ASN1::EntrezGene, BioPerl-run, BioPerl-db, BioPerl-network and
>>> The kind of thing that could then happen in the future is that (to
>>> 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
>>>>> "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
>> 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
>>>> 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
> 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
More information about the Bioperl-l