[cgiapp] CGI::Session

Wed Jul 6 22:01:57 EDT 2011

Hi Josh

On Wed, 2011-07-06 at 21:23 -0400, Joshua Miller wrote:
> 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.

This is discussed now and again. There's nothing wrong in spelling out
your position.

I used to use 0 for all module versions, but that caused problems, so I
adopted the policy of using what I had installed.

I don't think there's a perfect answer, since the definitive solution
(which is unrealistic) is to install many versions of many modules in
order to test all cross-combinations.

It is possible, especially now we have perlbrew, to install various
Perls, but then which version of Perl do we (module authors) target?
Module::CoreList is relevant here.

Perl::MinimumVersion does not yet test module dependencies.

Module::AutoInstall would be unacceptable to some users who did not want
such auto-action to take place.

As for Data::Dumper, examining
http://search.cpan.org/~smueller/Data-Dumper-2.131/Changes suggests V
2.124 would be fine. That's what I have with Perl V 5.10.1, presuming I
did not upgrade Data::Dumper.

OK - here's what I'll do.

I'll use perlbrew to install a fresh copy of 5.10.1.

My system Perl (5.10.1) is Debian's 6.0.2, but I won't use that, since I
may have upgraded modules before switching to perlbrew, even though
I /think/ I only ever used cpanm to upgrade modules.

Then I'll check the versions in 5.10.1 with the modules I actually use
in Data::Session, and report back.

> 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.
> 
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
> 
> 

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622