[Bioperl-l] Can we make Clone a required module so that automatic installation works?

[Scott Cain]

Hi Chris,

The 5 or 6 emails that all came within a few minutes of each other were
from me going to the bioperl-l moderation page and allowing them through (a
few were from February; guess I haven't done that in a while).  Are they
getting posted to the google list but not bioperl-l, and they're supposed
to?

Scott



On Mon, Mar 17, 2014 at 2:49 PM, Fields, Christopher J <
cjfields at illinois.edu> wrote:

> Huh, for some reason the bioperl-l google group replies aren't being
> bounced back to the list.
>
> Okay, I'll address each point below...
>
> On Feb 26, 2014, at 11:40 AM, george.hartzell at gmail.com wrote:
>
> > In short, I can't do this:
> >
> >  cpanm -L FOO BioPerl-1.6.923.tar.gz
> >
> > which makes me Very Sad.
> >
> > I've followed up on an existing issue about this here:
> >
> >  https://redmine.open-bio.org/issues/3447
> >
> > A hacked version of the tarball that moves Clone from a recommended
> module
> > to a required module (Build.PL, META.{json,yaml}) lets all of our tests
> > pass and keeps me from being Very Sad.
> >
> >
> >   - What's the right fix?
>
> Make Clone required (now committed in the 1.6.x branch).  On master branch
> it makes no sense to do this, as the requirement is at the Bio::Root level
> (and there is a req for Bio::Root in place now).  So, this will also be
> added to the Bio-Root repo.
>
> >   - Is our test broken?
>
> Not sure; the failure is an indication that Storable::dclone is
> problematic for cloning instances.  There is a possible fix (I alluded to
> it in the reply that didn't go to the list), but really, it would be much
> simpler to just require Clone instead.
>
> >   - Is there some reason to not require Clone (particularly if we
> actually
> >   require it to function correctly?
>
> Mentioned above.
>
> >   - Should we prefer Clone::Fast?
>
> Not sure; as I also mentioned (but will reiterate here for posterity)
> there may be OS-related problems.
>
> Also (and somewhat strangely) Clone::Fast is only on search.cpan.org and
> not on metacpan, which makes me wonder about it's status; there is a
> replacement called Data::Clone that is supposed to be faster and that no
> longer mentioned Clone::Fast.  Maybe it's been removed?
>
> That might simplify things for the time being...
>
> >   - If we want to present the Bio::* consumer with a choice, is driving
> >   that choice by whatever cloner happens to have been dragged in from God
> >   Knows Where the best way to do it?
>
> It should minimally work with something, and work better with something
> else.  That something should be (minimally) Clone, and if Clone::Fast is
> present then it can be used instead.
>
> Maybe we can simply default to Clone, and if a clone class is specified
> (via a global or env variable) use that instead.
>
> > So many questions....
> >
> > Thoughts, comments?
> >
> > g.
>
> For some context: the use of 'clone' here was meant to address a missing
> core function, namely a way to simply copy an instance (and possibly modify
> the copy on the fly if needed).  So far it has worked with only a few
> hiccups.
>
> chris
>
>
> _______________________________________________
> 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