[Bioperl-l] deprecated modules

Jason Stajich jason@cgt.mc.duke.edu
Sun, 18 Aug 2002 17:44:15 -0400 (EDT)


On Thu, 15 Aug 2002, Peter Kos wrote:

> Hi,
>
> Bio::Tools::Blast has been deprecated for a while - but it still
> works.
>
> I hope good old scripts will be easy to adjust to work with the new
> set of modules.
>
> What is the benefit from removing them? Will they cause problem with
> respect to the self-compatibility and homogeneity of the whole
> toolset in later versions?

Homogeneity, confusion, the toolkit is too scary for people as it is.
When they are looking for a logical thing to do blast parsing they
pick the first thing they see.  Then they find it hard to use or it
doesn't work and they give up.

I'm not a big fan of people reporting bugs in Tools::Blast and my first
response being, don't use that module its not supported, etc..  Yet it
happens all the time.

> I would feel that it may be enough to state clearly that they are
> deprecated so that new scripts should not use them. If these modules
> do not cause too much trouble for you, I would not mind wasting that
> much diskspace. Even now I store the whole Bioperl, although lots of
> the modules will never be necessary for me, and I am happy to have
> all of them under my fingertip, just in case.

You can always get the old modules from previous releases or CVS. If you
want to keep using Tools::Blast use an older version of the toolkit which
contains it.  It can just be in your PERL5LIB or still installed.

> There may be hundreds if not thousands of scripts using the
> deprecated modules worldwide, and they may later cause problems on
> machines with only brand-new installations of Bioperl.
>

They can continue to use and install older version of bioperl if that is
the need, but we have to move forward.  Keeping old unsupported modules in
the toolkit is bad for users who are new to the system and pick up the
most logically named module for their tool.  The original design of the
toolkit was not perfect, nor is it perfect now.  It will continue to mold
towards what people want to accomplish and support.  We needed a better
pluggable and extensible system for parsing search reports that do not end
up with redundancies.  Hence SearchIO.  I do not want to support > 1 blast
parser in Bioperl without good reason.

I feel uncomfortable releasing code with a module which I KNOW doesn't
work for certain cases (this is in no way a slight towards SteveC, but the
data providers, compute providers, formats, etc change).  So it has been
deprecated.  It doesn't conform to a lot of the newer inheritance and it
is very difficult for people to get in and read.

> I also understand that redundancy may lead to confusion, but
> TIMTOWTDI, as the Camel says.

Not when you are trying to release a software pkg that is stable and
extensible.  There should be a set of consistent rules that developers
working in concert should try and follow so that an outside observer can
follow those rules and understand how the pkg is organized.  This is an
unrealized dream of course, but something we need to strive for.

There in fact should be a lot of consistency in the pkg otherwise people
are totally lost and modules are not easily extended.

We have to be pretty explicit and disciplined if we want to manage
reasonable OO out of Perl so TIMTOWTDI is not always a good mantra when
you want to design reusable modules for an audience that may not be perl
saavy.

-jason

>
> Cheers
> Peter
>
> On Thursday, August 15, 2002 3:22 AM, Jason Stajich
> [SMTP:jason@cgt.mc.duke.edu] wrote:
> > Bio::Tools::Blast has been deprecated for a while - I'd like to
> > remove it from the trunk.  Additionally I'd like to remove
> Bio::UnivAln as it
> > too has been deprecated.  Steve and I have agreed that
> > Bio::SearchIO::psiblast, Bio::Search::HSP::BlastHSP
> > Bio::Search::Hit::BlastHit, and Bio::Search::Result::BlastResult
> > will be deprecated in 1.2 assuming we get all the functionality
> moved over
> > to the SearchIO::blast and XX::GenericXX objects.
> >
> > I can create a DEPRECATED file to list module history like this:
> >
> > # These are modules which are deprecated and later removed from the
> > toolkit
> >
> > Deprecated Modules     Version Deprecated   Version Removed
> > --------------------------------------------------------------
> > Bio::Tools::Blast            1.0	          1.1
> > Bio::Tools::Blast::HSP       1.0		  1.1
> > Bio::Tools::Blast::HTML      1.0		  1.1
> > Bio::Tools::Blast::Sbjct     1.0		  1.1
> >
> > Bio::Tools::WWW		     1.1
> >
> > Bio::UnivAln		     1.0		  1.1
> >
> >
> > My feeling is that BPlite currently still serves a purpose and
> > should stay
> > on the trunk, but it might need some maintence/testing at some
> > point.
> >
> > Shout if you don't want to see this happen.
> >
> > -jason
> > --
> > Jason Stajich
> > Duke University
> > jason at cgt.mc.duke.edu
> >
>
> ..................................................................
> ..........
> Peter B. Kos
> (RITE)
> kos@rite.or.jp
>

-- 
Jason Stajich
Duke University
jason at cgt.mc.duke.edu