[Bioperl-l] BioPerl 1.6 RC1
Chris Fields
cjfields at illinois.edu
Sat Jan 3 17:39:11 UTC 2009
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
More information about the Bioperl-l
mailing list