Item10413: Fn_MAKETEXT tests fail with deprecated defined hash syntax

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Urgent Closed Engine I18N, MAKETEXT  
Running the unit tests from a default configuration. (./pseudo-install -A )

  • core/lib/CPAN/lib/Locale/Maketext/Lexicon.pm shipped with Foswiki is not compatible with perl 5.12. defined %hash is deprecated. We should probably upgrade to the latest version. This patch resolves the issue if we choose to not upgrade. If I rename the Foswiki provided version, my system installed version 0.82 works okay. We supply 0.49.

diff --git a/core/lib/CPAN/lib/Locale/Maketext/Lexicon.pm b/core/lib/CPAN/lib/Locale/Maketext/Lexicon.pm
index 0bc7ff1..7fe8142 100644
--- a/core/lib/CPAN/lib/Locale/Maketext/Lexicon.pm
+++ b/core/lib/CPAN/lib/Locale/Maketext/Lexicon.pm
@@ -287,7 +287,7 @@ sub import {
             no strict 'refs';
             eval "use $class\::$format; 1" or die $@;
 
-            if (defined %{"$export\::Lexicon"}) {
+            if ( %{"$export\::Lexicon"}) {
                 if (ref(tied %{"$export\::Lexicon"}) eq __PACKAGE__) {
                     tied(%{"$export\::Lexicon"})->_force;
                 }

  • If the LANGUAGE preference is not set, I18n.pm fails to initialize. Use of uninitialized value $tag in lc at /var/www/foswiki/trunk/core/lib/Foswiki/I18N.pm line 51. The following patch resolves the issue. See also Item10267 for another possible solution. (Fixed under that task)

-- GeorgeClark - 26 Feb 2011

That's exactly why I hate us shipping 3rd party modules... We never update those, so they get out of date or have issues and we don't know about it until somebody complains, or perl gets upgraded and gets smarter.

I would vote for upgrading the shipped version of Lexicon, or splitting the release:
  • The core
  • The CPAN libraries one might need, which we could even directly download from CPAN, or tell people to install using their favorite OS packager

-- OlivierRaginel - 28 Feb 2011

This project has a very short memory

Before we added the essential CPAN libraries to be part of the distibution we had so many support requests from installers that did not know that they needed to install for example CGI::Session.

When we added this library the rate of support questions about this dropped several per week to nearly zero.

Installing CPAN libraries is geek stuff. It is not common knowledge. The core Foswiki needs to work as much as it can on standard Perl. And when it cannot we include the CPAN libs with Foswiki.

Yes it goes wrong sometimes. But it is not only this code that fails when upgrading to new Perl generations. We had plenty of these failures in our own code. It is actually very few problems we have had as a consequence of shipping the few CPAN libs that we ship.

Let us fix the problem and not go back to the horror days where we would have to tell someone on IRC nearly every day that they needed to install from CPAN library before they could get their wiki to work.

And for sure we should also go through the CPAN libs we ship and update them if needed for the new Perl versions.

-- KennethLavrsen - 28 Feb 2011

Hi George, do the Fn_MAKETEXT tests work for you on Release01x01 branch now? The whole test suite aborts early on Fn_MAKETEXT::simple with: Can't locate Foswiki/I18N/en_au.pm in @INC (for me)

-- PaulHarvey - 01 Mar 2011

They work here fine. I ran the unit tests before committing. That must be what is going on with the nightly tests as well. No idea what is going on other than something incompatible in the new CPAN Locale code. Should I revert?

-- GeorgeClark - 01 Mar 2011

I have absolutely no idea whatsoever, where to even begin looking... for what it's worth, my shell's LANG envar is en_AU.utf8.

But seeing perl try to load something named en_au.pm? Somehow I now have a new respect for how little I know about perl's I18N :-/

-- PaulHarvey - 01 Mar 2011

Note that to test foswiki web using the new CPAN libs, uncomment the line $CPANBASE = ''; in LocalLib.cfg and the CPAN will be flipped to the front of the libpath.

-- GeorgeClark - 02 Mar 2011

I added Locale::Maketext to our CPAN libraries. It appears that Locale::Maketext::Lexicon requires at least version 1.17 of Maketext. Although part of perl core, if it was backlevel, it might have been causing the issues? Nightly tests are working now at least for the Fn_MAKETEXT tests.

-- GeorgeClark - 02 Mar 2011

I think we have a problem with this fix. The issue is that the Foswiki CPAN is only used when the platform module is missing. So a platform with an out-of-date Maketext but missing Lexicon will fail due to incompatibility.
Locale::Maketext Locale::Maketext::Lexicon Status
missing missing Works
platform < 1.17 missing Fails
platform platform Works

Options?
  • Downgrade the shipped Maketext::Lexicon to a version compatible with older perl, and patch the "defined" bug
  • Add a Checker to report the mismatch and recommend enabling prepend in LocalLib.cfg

-- GeorgeClark - 02 Mar 2011

It appears that Maketext::Lexicon 0.82 doesn't need the 1.17 version of Maketext. Maybe this is a safer solution? It still has the fix for the "defined hash" issue. This would be simpler than adding checkers and asking people to upgrade Maketext, etc.

-- GeorgeClark - 02 Mar 2011

Downgraded Locale::Maketext::Lexicon to 0.79. 0.82 is removed from CPAN, and cpantesters.org shows good compatibility on 0.79. This also lets us remove Locale::Maketext 1.17 from the CPAN libs that we ship. I've also added Locale::Maketext to the DEPENDENCY file so that it shows up in the configure list for debugging purposes.

-- GeorgeClark - 02 Mar 2011
 
Topic revision: r29 - 16 Apr 2011, KennethLavrsen
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License