(except of course an existing code base that works with 5.6.1 and lack of resources for doing the testing necessary before an upgrade, plus the hassle of recompiling and reinstalling the modules with external dependencies)

You've got a point there. But on the other hand, what would you do? Wait another few years, and upgrade then? Or hope that whatever you do will become superfluous soon, or will be re-done from scratch?

Or spend years maintaining an abandoned perl version, working around myriads of Unicode bugs, memory leaks in closures and similar hassles?

The original questions shows that he is actively developing stuff, and slowly new versions of CPAN modules require higher minimal perl versions. Which means that you also have to start maintaining old versions of CPAN modules on your own.

Working around a broken environment is a daunting and time killing task. (I didn't program perl when 5.6.1 was state of the art, but from what I heard on various IRC channels it seems to be broken, compared by todays standards and compared to what's available today)

I don't know if there are viable solutions, but continuing to use old stuff certainly isn't very future proof, and the longer you wait the larger your system grows, and the hard it will become to upgrade in the end.

You know, there are situations where people are actively developing code on legacy hardware, where the old version of Perl is so much better than the alternative (Bourne, or if they're lucky, Korn shell), that they're not very likely to buck the hierarchy to try and compile a Perl on the old stuff. For one, the powers that be might not allow you to put a copy of gcc on a "one of" production box.

Things like Solaris 8 have a default Perl of the 5.005 variety. And yes, they get used for production all the time.

I would love to at least be using Perl 5.8 at this point, but I'm subject to two limitations which I cannot control directly (and may only influence indirectly):

1. the Perl version which is standard in the environment where I do my official development work
2. the Perl versions which are standard in the customer environments where my module may be deployed
That's why I'm currently at 5.6.1 - but I don't think my problems are related to my Perl distribution. In fact, you may have addressed my confusion in your first comment (use lib). I'll post another reply when I've had a chance to run some tests.

And don't forget my favorite -- having a vendor of a third party library that you have to use starting development using the newest library only when pushed by their clients.

An application I have to support is about 1-2 years behind supporting newest OS / DB / Perl (for example, they are still validating and compiling against 5.8.x, just released Oracle 10g support in January, and have now clue what the current revision of HP-UX is). We don't do "dot-oh" releases, and we have a boatload of local apps to validate against their release, putting us even further behind.

It is a never ending battle to try to have them find out where we are or would like to go a couple of years out rather than asking the question where are you now (yes, they would ask surveys based on current platforms, and then come to the conclusion that moving forward was not a priority; thankfully the surveys have started to change).

--MidLifeXis

Indeed, as you suggest I can put the RequestAgent.pm file into directory 'lib' and add "use lib 'lib';" to Client.pm prior to "use RequestAgent;".

This works as desired when I use the -Mblib command line argument to tell Perl where to find my libraries, if I the "use lib" directive in Client.pm contains a path for 'lib' which is relative to the directory specified by -Mblib. This is good.

But when I try to run "make test" from the lib/My/Client directory, I find that I get the following error:

Can't locate RequestAgent.pm in @INC (@INC contains: lib blib/arch bli
+b/lib /usr/lib/perl5/5.6.1/i386-linux ...(snip snip)... .) at blib/li
+b/My/Client.pm line 18.
[download]

1. tweak the "use lib" line in Client.pm gives the *full path* to 'lib' (horrors), or
2. move RequestAgent.pm into lib/My/Client/ and tweak Client.pm to "use lib 'lib/my/Client'"

But this seems lame, since in order to properly maintain both packages in the same directory I'll need to manually hack the local Makefile - or become enough of a MakeMaker guru that I can intelligently hack the upstream Makefile.PL instead.

Am I missing another option (perhaps something more obvious) here? Again, my goal here is simply to cleanly override the LWP credentials handler.

But when I try to run "make test" from the lib/My/Client directory

Why would you want to run 'make test' in that directory? Usually the directory structure for a module looks like this:

Makefile.PL
Makefile
lib/My/Client.pm
lib/OtherModules.pm
t/test-one.t
t/test-two.t
# other stuff
META.yml
important-script.pl
README
examples/example1.pl
[download]

If you adhere to that standard, your Makefile lives in the root directory, and the tests in a directory sub directory of the root dir.

So running make test on the lib/Foo/ level would actually complain about a Makefile not being found. So tests are always run from the root level directory, in which case make tests will invoke your test scripts as perl t/test-file.t.

In this case a use lib 'lib'; in all scripts that are invoked with the root dir as the current working directory.

I'm simply running "make" in the directory where h2xs created the Makefile.

My development sequence so far has been this:

1. Use h2xs to create the My::Client package skeleton.
2. Hack away at the skeleton until My::Client does almost everything I want it to.
3. Discover that I need to override the proxy credentials handling logic in the LWP::UserAgent package.
4. Look for the leanest/cleanest change which achieves the desired objective (hence this thread).

It sounds like you're saying that it is time for me to reorganize the directory structure of my package distribution.