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 <[email protected]> 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://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > > -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
