[cgiapp] CGI::Session

[Joshua Miller]

Hi all,

This is kinda picking at a sore spot for me, and I haven't seen any good
place to bring it up in the past.

On Wed, Jul 6, 2011 at 8:45 PM, Ron Savage <ron at savage.net.au> wrote:

> Hi Nick
>
> On Wed, 2011-07-06 at 14:35 +0100, Nicholas Bamber wrote:
> > Ron,
> >       You put an explicit version on every dependency. For example
> > Data::Dumper 2.128. That seems unnecessarily modern and Debian curently
> > only has 2.125. If we added the latest version as a package it might
> > need to be removed again later on.
>
> I put in the version #s as per what I have installed.
> I'm using perlbrew & V 5.12.2.
> I'll examine how to wind back these requirements...
> I had a look at /usr/lib/perl/5.10.1/Data/Dumper.pm and it says V 2.124.
> I could do that for each pre-req.
>
>
Module dependency minimum versions are one of the areas that has become a
really irritating part of using CPAN for me. If an author *knows* they need
some minimum version of something else, maybe because previous versions
lacked a feature they need, then I'm all for including the version. I'd even
allow that, in most cases, there probably *is* some minimum version that's
needed. What bugs me is the auto-generated minimum version requirements get
put in there based on what the author happens to have installed... they're
rarely even technically needed - it just happened to be what the author was
using when they built the module.

In your example, why would Data::Dumper V 2.123 not work with this module?
or one of far lower version? Just a hunch, but I'm betting they would... so
why force everyone to update all those other modules to what you happen to
have installed?

I really hope this doesn't offend anyone. I'm sure there's some good
arguments for including a minimum version... even if it's just whatever  you
have installed. At least then, you know it tested good on what you had
installed I guess. But isn't that the point of CPAN testers? If you don't
know what version of Data::Dumper is needed, don't specify it. Then, if a
test fails, you can see what version broke the test, and what version of
Data::Dumper would make it work again, and add that as the minimum version.

Maybe it's just a pet peeve of mine, but I'm betting it annoys some others
as well. I've stopped using CPAN to install stuff because of this. Now, if
it's not available in the package manager, I download and install manually.
If it complains about a module I have installed that doesn't match a version
it wants, then I go to the trouble of seeing if there's any comments in the
Makefile.PL or Build.PL... and if not, I remove the version requirement and
see if the tests pass. It's a pain, but less hassle than upgrading lots of
modules that were installed via a package manager, forcing me to maintain
those myself now (and resulting in multiple versions being installed).


>       Also do we really need all this DBIx stuff?
>
> The test code uses DBIx::Admin::CreateTable and DBIx::Admin::DSNManager.
> Data::Session doesn't. Of course that code could be re-written and
> included within Data::Session without those modules. I'm reluctant to do
> that, because there's already a Deb package for DBIx::Admin::CreateTable
> (that's why 'All rights reserved' was removed from the licence section
> in V 2.06), and I believe DBIx::Admin::DSNManager deserves its own Deb
> package. Nevertheless, if you think it's worth rewriting that code, feel
> free to say so.
>

If it's only the test code that uses it, IMO it shouldn't be a requirement.
The test should be written to skip those tests if the module isn't there.
Just like (nearly) all pod tests that need Test::POD. They just print a
warning that along the lines of "SKIPPING: Test::POD not installed". Seems
like that would be perfectly acceptable here.

DBD::Informix requirements drive me up a wall... you can't compile it
without an active Informix DB  you can actually connect to. I'd be ok if
only the tests require that, but it doesn't allow you to just skip the
tests... you can't make the Makefile without a connection. That's mostly
unrelated to this, but it's in the same vein... an test that isn't needed
for the module to work shouldn't be required.


Just my two cents on the matter... sorry for butting in :-)
--
Josh I.