in reply to Re: How to define a package using a tweaked version of LWP::UserAgent?
in thread How to define a package using a tweaked version of LWP::UserAgent?

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]
*unless* I either:
  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'"
Since I hate hardcoded file paths I find myself forced to use the second option.

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.

  • Comment on Re^2: How to define a package using a tweaked version of LWP::UserAgent?
  • Download Code

Replies are listed 'Best First'.
Re^3: How to define a package using a tweaked version of LWP::UserAgent?
by moritz (Cardinal) on Jul 31, 2008 at 16:08 UTC
    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.

[reply]
[d/l]
[select]

      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.

[reply]
        I'm just trying to describe how most modules organize their directories, and so far it worked out very well for me.

        If you put all your modules in the distribution under lib/, and run your script from directly above lib (aka root for the distribution dir), all you need is a simple use lib 'lib'.

        For installed modules this usually doesn't matter, because make install puts them in a directory below @INC where perl can find it.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom