[Bioperl-l] Bio::Graphics::Pictogram
Shawn Hoon
shawnh at gmail.com
Tue Jan 6 02:41:31 UTC 2009
hi Lincoln,
I no longer maintain Pictogram actively and from the log it has not
been worked on for a while as far as I can tell.
I would leave it up to bioperl as to whether it should still be
maintained via SVN or be deprecated.
cheers,
shawn
On Jan 5, 2009, at 11:34 PM, Lincoln Stein wrote:
> 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>
> _______________________________________________
> 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