CPAN tool problems, Windows XP

I'm having problems using CPAN under ActiveState Perl (version looks
like 5.6.1 as far as I can tell) on Windows XP Home. I installed
ActiveState Perl as straightforwardly as possible -- double-click on
the installer icon and let it run -- on an otherwise Perl-less machine
(no other/earlier versions previously present).

The FIRST time I try to use CPAN to install, say, Time::Format, I get a
series of messages indicating that various files --

\.cpan\sources\authors\01mailrc.txt.gz
\.cpan\sources\modules\02packages.details.txt.gz
\.cpan\sources\modules\03modlist.data.gz

-- are not retrieved from www.perl.org (or whatever the URL is; I don't
have a capture of that). On all subsequent attempts to use CPAN, then,
the above-mentioned files are reported as not containing what they're
supposed to. Inspection shows that the files EXIST but are EMPTY (0
bytes).

Seems to me I've done this successfully in the past -- but I don't
remember whether that was under Windows XP or on a different machine
running 2000.

Thanks in advance for any advice anyone can give me regarding getting
this to work. I use Perl at an "advanced beginner" stage sufficiently
frequently that I need it to work, but am not advanced enough to be
able to debug CPAN by my lonesome. :-)

The following, as best I can capture it, is what I see on the
non-first-time installations. I may be able to re-create the
first-time experience by deleting the affected files, but perhaps that
won't be necessary. Thanks again.

cpan shell -- CPAN exploration and modules installation (v1.59_54)
ReadLine support available (try 'install Bundle::CPAN')

CPAN: Storable loaded ok
Going to read \.cpan\sources\authors\01mailrc.txt.gz
CPAN: Compress::Zlib loaded ok
Going to read \.cpan\sources\modules\02packages.details.txt.gz
Warning: Your \.cpan\sources\modules\02packages.details.txt.gz
does not contain a Line-Count header.
Please check the validity of the index file by comparing it to
more
than one CPAN mirror. I'll continue but problems seem likely to
happen.
Warning: Your \.cpan\sources\modules\02packages.details.txt.gz
does not contain a Last-Updated header.
Please check the validity of the index file by comparing it to
more
than one CPAN mirror. I'll continue but problems seem likely to
happen.
Going to read \.cpan\sources\modules\03modlist.data.gz
Can't locate object method "data" via package "CPAN::Modulelist"
(perhaps you forgot to load "CPAN::Modulelist"?) at (eval 9) line 1.
CPAN::Index::rd_modlist('CPAN::Index',
'\.cpan\sources\modules\03modlist.data.gz') called at
c:/Perl/lib/CPAN.pm line 3002
CPAN::Index::reload('CPAN::Index') called at c:/Perl/lib/CPAN.pm
line 620
CPAN::exists('CPAN=3DHASH(0x19eb494)', 'CPAN::Module',
'Time::Format') called at c:/Perl/lib/CPAN.pm line 1735
CPAN::Shell::expandany('CPAN::Shell', 'Time::Format') called at
c:/Perl/lib/CPAN.pm line 1969
CPAN::Shell::rematein('CPAN::Shell', 'install', 'Time::Format')
called at c:/Perl/lib/CPAN.pm line 2056
CPAN::Shell::install('CPAN::Shell', 'Time::Format') called at
c:/Perl/lib/CPAN.pm line 183
eval {...} called at c:/Perl/lib/CPAN.pm line 183
CPAN::shell() called at -e line 1
=20
Lockfile removed.

Re: CPAN tool problems, Windows XP

"Chris" wrote:

> I'm having problems using CPAN under ActiveState Perl (version looks
> like 5.6.1 as far as I can tell) on Windows XP Home.

I recommend to use:
This is perl, v5.8.8 built for MSWin32-x86-multi-thread

furthermore, I always install modules using ppm, which comes with
ActiveState.

ppm install Time::Format

Re: CPAN tool problems, Windows XP

Chris wrote:
> I'm having problems using CPAN under ActiveState Perl (version looks
> like 5.6.1 as far as I can tell) on Windows XP Home. I installed
> ActiveState Perl as straightforwardly as possible -- double-click on
> the installer icon and let it run -- on an otherwise Perl-less machine
> (no other/earlier versions previously present).
>
> The FIRST time I try to use CPAN to install, say, Time::Format, I get a
> series of messages indicating that various files --
>
> \.cpan\sources\authors\01mailrc.txt.gz
> \.cpan\sources\modules\02packages.details.txt.gz
> \.cpan\sources\modules\03modlist.data.gz
>
> -- are not retrieved from www.perl.org (or whatever the URL is; I don't
> have a capture of that). On all subsequent attempts to use CPAN, then,
> the above-mentioned files are reported as not containing what they're
> supposed to. Inspection shows that the files EXIST but are EMPTY (0
> bytes).



Second John Bokma's recommendation in the adjacent reply. But -

Are you behind a proxy server? If you are, you will need to correctly
configure LWP::UserAgent and/or define environment variable HTTP_PROXY
and/or FTP_PROXY to point to the correct server and port. This will need
to be done even if you use ppm.

My opinion is that CPAN does not work very well under Windows (and that
includes cygwin) because Windows won't let you replace a DLL that is in
use. This bites you when you install an update of an XS module that CPAN
actually uses (e.g. 'Cwd'). I used to keep a mental list for use with
cygwin, but it's all gone except for 'Cwd', which _does_ get updated. As
I recall, the procedure is to run the update through the test, then bail
out of _all_ instances of Perl (tricky if you're running a Perl-based
service), cd to the CPAN directory containing your distribution, and do
the "make install" by hand. I have sometimes had to manually delete the
files being replaced, but again this was under cygwin.

Tom Wyant

Re: CPAN tool problems, Windows XP

John Bokma wrote:
> "Chris" wrote:
>
> > I'm having problems using CPAN under ActiveState Perl (version looks
> > like 5.6.1 as far as I can tell) on Windows XP Home.
>
> I recommend to use:
> This is perl, v5.8.8 built for MSWin32-x86-multi-thread

Thanks, I was thinking of upgrading, myself, and this just reinforces
the idea. I appreciate it.

> furthermore, I always install modules using ppm, which comes with
> ActiveState.
>
> ppm install Time::Format

Aha! THAT works! Simple solution. Thanks bunches!

Chris

Re: CPAN tool problems, Windows XP

harryfmudd [AT] comcast [DOT] net wrote:

> ...
>
> Are you behind a proxy server? If you are, you will need to correctly
> configure LWP::UserAgent and/or define environment variable HTTP_PROXY
> and/or FTP_PROXY to point to the correct server and port. This will need
> to be done even if you use ppm.

I'm not quite sure whether I'm behind a proxy server. I have a
wireless router that presents one IP address to the outside world, and
another to machines inside my house. Is THAT a proxy server?

Is it significant that I just tried PPM and it works?

How do I "configure LWP::UserAgent"? I must have missed the doc (if
any) on how to do that.

> My opinion is that CPAN does not work very well under Windows (and that
> includes cygwin) because Windows won't let you replace a DLL that is in
> use. [...]

So you're saying that the CPAN module tries to replace DLLs that Perl
uses. Hadn't thought of that. Haven't gotten far enough for that to
be an issue, yet, actually. :-P So I'd guess this would affect PPM
as well as CPAN?

C.

Re: CPAN tool problems, Windows XP

Chris wrote:
> harryfmudd [AT] comcast [DOT] net wrote:
>
>
>>...
>>
>>Are you behind a proxy server? If you are, you will need to correctly
>>configure LWP::UserAgent and/or define environment variable HTTP_PROXY
>>and/or FTP_PROXY to point to the correct server and port. This will need
>>to be done even if you use ppm.
>
>
> I'm not quite sure whether I'm behind a proxy server. I have a
> wireless router that presents one IP address to the outside world, and
> another to machines inside my house. Is THAT a proxy server?
>

No. If you were behind a proxy server you would have to connect to it
rather than the world at large.

> Is it significant that I just tried PPM and it works?

Yes. If PPM worked without defining www_proxy it means you are not
behind a proxy server.

>
> How do I "configure LWP::UserAgent"? I must have missed the doc (if
> any) on how to do that.
>

I think I was confused when I said that. When I was composing my reply I
thought I remembered going through a configuration that asked me to
tell it about (among other things) proxy servers. But I believe now that
that's the CPAN configuration, because I can't find any configuration
docs for LWP::UserAgent either. The LWP docs tell about the environment
variables.

>
>>My opinion is that CPAN does not work very well under Windows (and that
>>includes cygwin) because Windows won't let you replace a DLL that is in
>>use. [...]
>
>
> So you're saying that the CPAN module tries to replace DLLs that Perl
> uses. Hadn't thought of that. Haven't gotten far enough for that to
> be an issue, yet, actually. :-P So I'd guess this would affect PPM
> as well as CPAN?
>

Well, ActivePerl seems to have solved this problem somehow - maybe by
restricting the modules used by ppm, making those part of their core,
and then not updating them other than by making you install a new Perl.

Judging by what happened when I added Module::Build support to some of
my packages, they're using a fairly old version of ExtUtils::MakeMaker,
and I suspect you'll find the Cwd a couple revisions behind CPAN as well.

Tom Wyant

Re: CPAN tool problems, Windows XP

harryfmudd [AT] comcast [DOT] net wrote:
> Chris wrote:
> > harryfmudd [AT] comcast [DOT] net wrote:
> >
> > wireless router ... Is THAT a proxy server?
> >
> No. If you were behind a proxy server you would have to connect to it
> rather than the world at large.

Thanks; now I'll know what to tell the next person (or program) that
asks!

> > Is it significant that I just tried PPM and it works?
>
> Yes. If PPM worked without defining www_proxy it means you are not
> behind a proxy server.

I may have been premature when I said that it "worked," but maybe it
depends on your definition of "worked." It definitely picked up, and
installed, a version of Win32::GUI ... but I had problems getting it to
work, went to CPAN, couldn't make sense of what was available there,
got in touch with the author (Robert May), ended up getting on his
Win32-users mailing list, and have determined that PPM probably picked
up a way-old PPM package? module? whatever from the
not-recently-updated ActiveState repository.

So now I'm up against trying to find a more "current" one, -or-
contrive to build it from scratch. I don't have any more time to spend
on it right now, either way, so am going to have to take another run at
it sometime later.

> > How do I "configure LWP::UserAgent"? I must have missed the doc (if
> > any) on how to do that.
>
> I think I was confused when I said that. When I was composing my reply I
> thought I remembered going through a configuration that asked me to
> tell it about (among other things) proxy servers. But I believe now that
> that's the CPAN configuration, because I can't find any configuration
> docs for LWP::UserAgent either. The LWP docs tell about the environment
> variables.

Yeah, I see some blatherings about LWP when I try to use the CPAN
module.

> >>My opinion is that CPAN does not work very well under Windows ...

Others -- e.g. Robert May :-) -- agree with you on this.

> Judging by what happened when I added Module::Build support to some of
> my packages, they're using a fairly old version of ExtUtils::MakeMaker,
> and I suspect you'll find the Cwd a couple revisions behind CPAN as well.

Whew. I'm sufficiently new-and-inexperienced at all this, that I'm not
really familiar with Module::Build, ExtUtils::MakeMaker, and/or "the
Cwd." Care to explain, either here or (so as not to bore people who
already know it) via e-mail?

Thanks again,

Chris

Re: CPAN tool problems, Windows XP

Chris wrote:



>
> So now I'm up against trying to find a more "current" one, -or-
> contrive to build it from scratch. I don't have any more time to spend
> on it right now, either way, so am going to have to take another run at
> it sometime later.
>
>

You'll need at least nmake. My crib notes say you can get it from
ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe but there may well
be more current versions available. Some modules need a "C" compiler. If
you look in a module and it contains file names ending in ".xs", you
need one. Once upon a time it was Visual C++ or nothing, but I have
heard (on this newsgroup) that MinGW also works, and is much cheaper.



>
> Whew. I'm sufficiently new-and-inexperienced at all this, that I'm not
> really familiar with Module::Build, ExtUtils::MakeMaker, and/or "the
> Cwd." Care to explain, either here or (so as not to bore people who
> already know it) via e-mail?
>

The canonical way to build a Perl module looks something like this:

gunzip module.tar.gz
tar -xf module.tar
cd module
perl Makefile.PL
make
make test
make install

(other things might appear instead of 'make' - e.g. 'nmake' under
Windows, 'mmk' under VMS, or whatever).

Yes, you can use WinZip for the first two steps. And at least some tars
let you skip the 'gunzip' in favor or

tar -xzf module.tar.gz

but that's kind of tangential to our discussion.

The only thing Makefile.PL is really required to do is do some
requirements checking and generate a file named 'Makefile', or whatever
the make utility wants. But makefiles are complicated, so it's usual for
Makefile.PL to delegate its dirty work to a Perl module called
ExtUtils::MakeMaker. This gets installed when you install Perl, so it's
pretty well guaranteed to be there, and is pretty much the standard way
for a module author to get his or her module installed.

But ExtUtils::MakeMaker needs external programs (e.g. at least 'make')
to get its job done. Because Perl is perfectly capable of doing the job
'make' gets used for, another build system called Module::Build arose,
which minimizes the need for external programs (except for compilers, of
course). Modules which use Module::Build are built using a slightly
different canonical incantation:

gunzip module.tar.gz
tar -xf module.tar
cd module
perl Build.PL
../Build
../Build test
../Build install

When the author provides both build systems there can be problems,
because older versions of ExtUtils::MakeMaker assume that any file named
*.PL needs to be run, which causes errors if the module author provides
a Build.PL buit Module::Build is not installed. Newer versions of
ExtUtils::MakeMaker are smart enough to deal with this, but older
versions have to be told "don't run any .PL files".

Cwd is something else altogether. It's the module that fetches the name
of the current directory. It also provides functionality to convert a
path name to absolute. This module is part of the Perl core, but gets
updated occasionally on its own. ActiveState, however, considers it part
of the core and lets it go at that, since it requires a dll (i.e. it's
one of those .xs modules I talked about earlier) and is hard to replace.

ActivePerl installs the Perl documentation as browsable HTML. You should
look into it for more on (at least) Cwd, and probably ExtUtils::MakeMaker.

Tom Wyant