[Bioperl-l] Bio::Graphics::Pictogram
Lincoln Stein
lincoln.stein at gmail.com
Mon Jan 5 10:34:38 EST 2009
Hi Shawn,
You may or may not know that during the preparation for BioPerl 1.6 we split
Bio::Graphics off into its own CPAN distribution and are now hosting its CVS
at Sourceforge. During the split, I inadvertently grabbed
Bio::Graphics::Pictogram and moved it into Sourceforge along with the rest
of Bio::Graphics.
Do you want to maintain Pictogram out of Sourceforge (I will give you
developer access), or move it back into BioPerl for SVN maintenance and
release as part of the main Bioperl distribution?
Lincoln
On Sat, Jan 3, 2009 at 12:39 PM, Chris Fields <cjfields at illinois.edu> wrote:
> 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
>>
>
>
--
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>
More information about the Bioperl-l
mailing list