LWP install MacOS X

[Henry]

Folks:

I need LWP. It doesn't come with Jaguar.

OK, it's time to go CPAN. Download LWP. No problem. But it won't install
unless URI, HTML:arser, MIME::Base64, Net::FTP (libnet), Digest::MD5 and
maybe some other stuff are already installed.

I get an error message that explains:

"... MakeMaker could not find "/System/Library/Perl/darwin/CORE/perl.h"

Googling on this filename ... Some helpful person has posted the answer: I
need the MacOS X Developer Tools, I'm likely to end up fighting a
case-sensitivity issue, and _he_ ended up doing a complete perl 5.8.0
install in a new place.

This LWP install is fast showing signs of being an infinite process; I'm
expecting, by tomorrow, to be told I need to cast new silicon for the
PowerPC processor!

Can someone confirm generally that all this needs to be done to get LWP
functionality? That this process is actually do-able within a reasonable
amount of time, without additional tangled sub-dependencies? Maybe suggest
a simplified procedure?

Yes, I've checked the perl and CPAN FAQs. The page "What To Do Once You've
Downloaded A Module From The CPAN" is really nice.

Thanks,

Henry

(e-mail address removed) remove 'zzz'

 

[Sherm Pendley]

OK, it's time to go CPAN. Download LWP. No problem. But it won't install
unless URI, HTML:arser, MIME::Base64, Net::FTP (libnet), Digest::MD5 and
maybe some other stuff are already installed.

If you use the CPAN shell (perldoc CPAN), it will manage those
dependencies for you. It'll still need to download and install a bunch
of stuff, which can be time-consuming if you're using a modem. But at
least you won't have to figure out what you need and install it all by hand.

A tip about using CPAN on Jaguar: DON'T take its suggestion and install
Bundle::CPAN. There's a bug in the version of CPAN.pm that's shipped
with Jaguar, that will result in it attempting to upgrade your whole
Perl installation if you do that.

Instead, upgrade just the CPAN module by itself first - "install CPAN"
at the CPAN shell. Once you have the latest CPAN module, it's safe to
use it to install all the other goodies with "install Bundle::CPAN".

Another tip: When CPAN is configuring itself, it will ask you a series
of questions. Some of them need y/n answers, but others need directory
paths. A very common mistake is to fall into a rythm of answering "y" to
every question, and then accidentally entering "y" when a question that
needs a directory path comes up.

"... MakeMaker could not find "/System/Library/Perl/darwin/CORE/perl.h"

Googling on this filename ... Some helpful person has posted the answer: I
need the MacOS X Developer Tools

Yes, you do. Many Perl modules are wrappers around binary libraries, and
among other things, you'll need GCC - the C compiler included with the
dev tools - to compile those wrappers.

, I'm likely to end up fighting a case-sensitivity issue

It's not much of a fight. More like a mild argument. ;-)

When the LWP module asks if you want to install /usr/bin/HEAD, just say
no. If you answer yes, it will overwrite /usr/bin/head, because HFS is
not case sensitive.

If you want to play it extra-safe, make a copy of /usr/bin/head. That
way, if you wind up replacing it with LWP's HEAD, you can easily restore
it from your backup copy.

sherm--

 

[Henry]

Sherm:

Thanks for your response on this thread:

If you use the CPAN shell (perldoc CPAN), it will manage those
dependencies for you. It'll still need to download and install a bunch
of stuff, which can be time-consuming if you're using a modem. But at
least you won't have to figure out what you need and install it all by hand.

Yeah, I tried that, too. A truly daunting amount of output, some of it a
bit scary. I guess one answers the questions (per your comments below) and
cover one's eyes during the progress messages. When it fails, you go back
and try to discover why.

Of course, again as per below, without the right ingredients, this recipe
fails, too.

A tip about using CPAN on Jaguar: DON'T take its suggestion and install
Bundle::CPAN. There's a bug in the version of CPAN.pm that's shipped
with Jaguar, that will result in it attempting to upgrade your whole
Perl installation if you do that.

OK. I hope I didn't do that. $%*$%!@@$!$, the console has scrolled so far
that's all fallen off the end.

Instead, upgrade just the CPAN module by itself first - "install CPAN"
at the CPAN shell. Once you have the latest CPAN module, it's safe to
use it to install all the other goodies with "install Bundle::CPAN".

Hmmm, I don't think I did that, so maybe I correctly focused on the
(hopeless) task at hand.

Another tip: When CPAN is configuring itself, it will ask you a series
of questions. Some of them need y/n answers, but others need directory
paths. A very common mistake is to fall into a rythm of answering "y" to
every question, and then accidentally entering "y" when a question that
needs a directory path comes up.

OK, got it. Thanks.

Yes, you do. Many Perl modules are wrappers around binary libraries, and
among other things, you'll need GCC - the C compiler included with the
dev tools - to compile those wrappers.

Right. I speak GCC, at least in other environments, so there's no
fundamental issue here. But I'm really surprised that I need to load the
better part of 1 GB of stuff to make a couple of standard(!) modules. Is
there no way to distribute these as binaries?

I'm not allergic to development tools, not at all, but I try to not get
unnecessarily entangled, unless I'm doing relevant ... development. I'm
not! No, I'm trying to use some standard modules in some completely
unrelated development It seems strange.

Strange or not, I went ahead and installed the development tools already
earlier today -- takes a while. When I return to this tomorrow, this should
all work perfectly, yes? (Right!)

It's not much of a fight. More like a mild argument. ;-)

When the LWP module asks if you want to install /usr/bin/HEAD, just say
no. If you answer yes, it will overwrite /usr/bin/head, because HFS is
not case sensitive.

"Just say no" eh? OK.

If you want to play it extra-safe, make a copy of /usr/bin/head. That
way, if you wind up replacing it with LWP's HEAD, you can easily restore
it from your backup copy.

Understood.

I'm also surprised this entire issue isn't better documented. Maybe I
missed something, but I did give it a good try -- several hours of hard
searching-- and came up mostly empty.

It should be clearer, in the general case of how modules are maintained and
ported, and I'm surprised there's not more specific information for MacOS
X. Or have I missed a great treasure-trove of docs?

Thanks,

Henry

 

[Sherm Pendley]

$%*$%!@@$!$, the console has scrolled so far
that's all fallen off the end.

That reminds me of another tip - I always go into Terminal.app's
preferences, and set the scrollback buffer to "unlimited." As you said,
the output from the build/install process can be verbose, and if it
fails you'll want to be able to review it from the beginning.

Right. I speak GCC, at least in other environments, so there's no
fundamental issue here. But I'm really surprised that I need to load the
better part of 1 GB of stuff to make a couple of standard(!) modules. Is
there no way to distribute these as binaries?

Fink has some pre-rolled modules packages, but I think they're all for
modules that have a binary component. IIRC, they don't have an LWP package.

Distributing binaries is also complicated by the fact that Panther ships
with Perl 5.8.1 - which is not binary-compatible with 5.6. Modules that
include compiled C code, which were compiled for 5.6 don't work with
5.8, and vice-versa. Anyone who creates binary packages has to create
them for both versions - and deal with the inevitable support issues
arising from users who install the wrong one.

I'm also surprised this entire issue isn't better documented. Maybe I
missed something, but I did give it a good try -- several hours of hard
searching-- and came up mostly empty.

A lot of the relevant discussion takes place on the (e-mail address removed)
mailing list - you can (un)subscribe and/or search the archives at

It should be clearer, in the general case of how modules are maintained and
ported, and I'm surprised there's not more specific information for MacOS
X. Or have I missed a great treasure-trove of docs?

One obstacle is that there isn't really a general case that applies to
all modules. The issue with HEAD vs. head, for example, only applies to
LWP - I don't know of any other module that attempts to install a file
where the file name is different from that of a system file only in
capitalization. And, the "don't install Bundle::CPAN" bug is not only
unique to CPAN.pm, but to a specific version of that module.

sherm--

 

[Henry]

Sherm:

Thanks for your response on this thread:

That reminds me of another tip - I always go into Terminal.app's
preferences, and set the scrollback buffer to "unlimited." As you said,
the output from the build/install process can be verbose, and if it
fails you'll want to be able to review it from the beginning.

Ummm, that's not really a great solution. "Unlimited" also means
potentially "unlimited" stuff to review and decode. That's _too_ much.
There has to be a middle ground, a better solution than the "hyper-verbose"
output that results.

I appreciate your help. I apologize for my irritability on this issue -- I
don't mean it personally -- it's just a sign of a person who wants to get a
job done and finds himself getting deeper and deeper in irrelevant details.

My workaround solution to avoid LWP and drop into the shell to use "wget" is
looking better and better. I just hope I haven't whacked my perl
installation altogether.

Fink has some pre-rolled modules packages, but I think they're all for
modules that have a binary component. IIRC, they don't have an LWP package.
Right.

Distributing binaries is also complicated by the fact that Panther ships
with Perl 5.8.1 - which is not binary-compatible with 5.6. Modules that
include compiled C code, which were compiled for 5.6 don't work with
5.8, and vice-versa. Anyone who creates binary packages has to create
them for both versions - and deal with the inevitable support issues
arising from users who install the wrong one

Yeah. I've seen all sorts of solutions for this issue, none of them
entirely satisfactory.

A lot of the relevant discussion takes place on the (e-mail address removed)
mailing list - you can (un)subscribe and/or search the archives at
<http://lists.perl.org>.

OK, looks good. Be better if there was a FAQ.

One obstacle is that there isn't really a general case that applies to
all modules. The issue with HEAD vs. head, for example, only applies to
LWP - I don't know of any other module that attempts to install a file
where the file name is different from that of a system file only in
capitalization. And, the "don't install Bundle::CPAN" bug is not only
unique to CPAN.pm, but to a specific version of that module.

I guess there's no formal mechanism for collecting and disseminating such
advice. Release notes for each module might mention such? I've seen such
in other environments.

Anyway, I fired up the CPAN shell this morning, having loaded the developer
tools yesterday. I foolishly took its suggestion to update and restart CPAN
itself. I killed the job when I found it downloading what-was-it 11 MB to
upgrade to perl-5.8.2. I did NOT ask for that -- there's no telling what
kind of ramifications will result.

It might be easier at this point to install Panther, except that I believe
I've seen mention that it shipped with an earlier version of perl then some
might find acceptable.

Using wget is sure looking attractive ...

Thanks,

Henry

(e-mail address removed) remove 'zzz'

 

[Sherm Pendley]

Ummm, that's not really a great solution. "Unlimited" also means
potentially "unlimited" stuff to review and decode. That's _too_ much.
There has to be a middle ground, a better solution than the "hyper-verbose"
output that results.

We seem to have shifted subjects. I wasn't referring to reducing the
amount of output - to my knowledge, there isn't a "quiet" option.

That said, you have to choose how to deal with the output: You can save
it in case you need to review it, or throw it away and hope for the
best. I don't like leaving things to chance, so I prefer to do the
first, and my advice to adjust Terminal.app's scrollback buffer
reflected that.

Anyway, I fired up the CPAN shell this morning, having loaded the developer
tools yesterday. I foolishly took its suggestion to update and restart CPAN
itself.

To put it bluntly, documentation and/or advice doesn't help if you
ignore it. Yesterday, I gave you very specific advice to first upgrade
the CPAN module by itself with "install CPAN", and *then* install
Bundle::CPAN. I clearly explained what would be the result of installing
the bundle first.

It might be easier at this point to install Panther, except that I believe
I've seen mention that it shipped with an earlier version of perl then some
might find acceptable.

Panther doesn't come with LWP pre-installed either, and it's no
different installing it there than on Jaguar.

I think the best advice I can give you right now is to step back and
leave it be for a day or two. Take the weekend off. It sounds like
you're getting frustrated and impatient, and you're letting that drive
you into making mistakes - as with the CPAN bundle above.

If you approach this calmly and clearly, you'll find it's much easier
than you're making it out to be. Upgrade the CPAN module by itself with
"install CPAN" before installing the CPAN bundle with "install
Bundle::CPAN". The latest LWP version takes case-insensitive filesystems
into account, and will ask you before installing /usr/bin/HEAD. When it
asks about that, simply tell it not to.

sherm--

 

[Henry]

Sherm:

Thanks for your response on this thread:

We seem to have shifted subjects. I wasn't referring to reducing the
amount of output - to my knowledge, there isn't a "quiet" option.

It was not my intention to shift subjects. A "moderately verbose" option
would be good, it doesn't exist , 'nuff said.

That said, you have to choose how to deal with the output: You can save
it in case you need to review it, or throw it away and hope for the
best. I don't like leaving things to chance, so I prefer to do the
first, and my advice to adjust Terminal.app's scrollback buffer
reflected that.


To put it bluntly, documentation and/or advice doesn't help if you
ignore it. Yesterday, I gave you very specific advice to first upgrade
the CPAN module by itself with "install CPAN", and *then* install
Bundle::CPAN. I clearly explained what would be the result of installing
the bundle first.

Ooooh, sorry...

Please help me understand: Are you suggesting that the only reason the CPAN
shell started downloading a newer version of perl is that I mulishly failed
to follow your advice? (I found a post somewhere that seems to say that
there's a bug in an older version of the shell that causes it to do this.)

I had your your post open on the desktop as I worked. I _thought_ I was
doing what you said. I still think I did: I'm pretty sure the CPAN shell
said something to the effect that I should upgrade it during the current
session, by typing (IIRC) "install CPAN". That seemed consistent with what
you advised.

I have no idea what "Bundle::CPAN" is, except that a very helpful perl guru
told me to avoid loading it first. (What's a "bundle", anyway?) I'm pretty
sure I did not either type anything containing "bundle" to the CPAN shell,
nor did I say "y" to any prompt that included that term, though something
like that might have snuck by.
A great deal of the issue is terminology. What's "CPAN"? It's "...a large
collection of Perl software and documentation", according to the
www.cpan.org FAQ. OK, no problem, makes sense.

The same term, I find, _also_ applies to a perl program that implements a
shell that helps get and install stuff from that large collection. I hadn't
a clue that definition #2 existed before yesterday or the day before. It
simply hadn't come up -- this isn't exactly publicized, at least in the
places I've looked. I've got over 50 perl reference sites bookmarked.

Panther doesn't come with LWP pre-installed either, and it's no
different installing it there than on Jaguar.

OK, good, that helps me decide.

I think the best advice I can give you right now is to step back and
leave it be for a day or two. Take the weekend off. It sounds like
you're getting frustrated and impatient, and you're letting that drive
you into making mistakes - as with the CPAN bundle above.

Right, always a good idea. I think I'll install my unix shell wget hack in
the meantime.

If you approach this calmly and clearly, you'll find it's much easier
than you're making it out to be. Upgrade the CPAN module by itself with
"install CPAN" before installing the CPAN bundle with "install
Bundle::CPAN". The latest LWP version takes case-insensitive filesystems
into account, and will ask you before installing /usr/bin/HEAD. When it
asks about that, simply tell it not to.

Yes, I can try.

I'm also collecting questions that would help me understand this process
more comprehensively. When it is ready, I probably should post it to the
perl/mac list you recommended.

Thanks,

Henry

(e-mail address removed) remove 'zzz'

 

[Sherm Pendley]

I had your your post open on the desktop as I worked. I _thought_ I was
doing what you said.

Sorry, my bad. I gave you outdated advice. :-(

Once upon a time, installing Bundle::CPAN would tickle the bug, whereas
installing just CPAN would not. So, the workaround was to install just
the module by itself, and once the module had been upgraded to a version
that didn't have the bug, then install the bundle.

As it happens, I've done some housecleaning recently, so I had a clean
Jaguar installation on another partition. So I booted into that and
tried upgrading CPAN.pm just to be certain, and sure enough, that
work-around no longer does the trick.

There are still some options - reconfiguring the CPAN shell to ask
before resolving dependencies, or not to resolve them at all, or
installing CPAN.pm by hand.

But you've indicated that you're not really interested in developing in
Perl, you just want to write a quick little script to get a job done.
With that in mind, upgrading CPAN.pm might be more trouble than it's
worth to you. If all you want is to install LWP, the CPAN.pm version
that you already have is perfectly capable of doing that.

Yes, I can try.

FWIW, While I was experimenting with Jaguar, I installed Bundle::LWP
too. The current version doesn't try to install /usr/bin/HEAD unless you
specifically ask it to. When it asks if you want to install it, the
default is "n".

So basically, what you're left with is, don't bother upgrading the CPAN
shell if all you want is to install LWP. The bug in LWP has been fixed,
so simply entering "install Bundle::LWP" and accepting all the defaults
will safely install it.

sherm--

 

[Henry]

Sherm:

Thanks for your response on this thread:

Sorry, my bad. I gave you outdated advice. :-(

No problem.

Once upon a time, installing Bundle::CPAN would tickle the bug, whereas
installing just CPAN would not. So, the workaround was to install just
the module by itself, and once the module had been upgraded to a version
that didn't have the bug, then install the bundle.

Right, thanks for letting me know.

As it happens, I've done some housecleaning recently, so I had a clean
Jaguar installation on another partition. So I booted into that and
tried upgrading CPAN.pm just to be certain, and sure enough, that
work-around no longer does the trick.

Glad to hear we're working on the same OS --a very decent environment, I
think-- and ...impressive that you have taken this level of precautions. I
have a hard drive just for backup, but I've never tried keeping a clean OS X
on it.

Thanks for going to the trouble of checking this for me!

There are still some options - reconfiguring the CPAN shell to ask
before resolving dependencies, or not to resolve them at all, or
installing CPAN.pm by hand.

"By hand..." Sure, no problem. I can do that, assuming there are few or no
dependencies to resolve. Actually, it's a lot less intimidating to me than
using the CPAN shell.

But you've indicated that you're not really interested in developing in
Perl, you just want to write a quick little script to get a job done.

Did I say that?

Please give me some middle ground. I picked a big project, did some
research, and discovered Perl offers the best tools to do help me do the
job, overall. Since then, I've been learning Perl by using it
intensively.

The only thing I new about Perl at the outset was that it had existed, and I
had two books about it ("Perl by Example" by Quigley and "Learning Perl" by
Schwartz), which I bought several years ago against the possibility that I
would eventually need Perl.

Do I want to make Perl a life's work? No. But I'm going to end up with a
significant chunk of what I hope to be reasonably good Perl code. That
means I need to learn the details, the idiom, the philosophy, and --yes-- a
bit about maintaining the environment. To be sure, I'd rather spend _less_
time on maintenance ...

If I've understood the Perl "philosophy" correctly, it would not be an
affront to throw together a quick little script to get a job done, not in
the least, but --no, this is a serious effort.

With that in mind, upgrading CPAN.pm might be more trouble than it's
worth to you. If all you want is to install LWP, the CPAN.pm version
that you already have is perfectly capable of doing that.

Right. I suspected that. But I'm not sure, and I'd like to be a bit more
certain, at least. Maybe CPAN.pm (better terminology, thanks!) will make
navigating the dependencies easier.

OK, so I'll ask explicitly: Given version 'n' of a particular module is
installed on your system, and you've found new module 'm', how can one
figure out the importance--necessity-- advisability-- safety--chances of
success of installing the newer one?

This goes beyond finding a list saying "version m fixes _these_ bugs, and
adds _those_ features" but it is at the heart of the job of maintaining a
particular installation.

Same question for the next dot revision of Perl itself.

FWIW, While I was experimenting with Jaguar, I installed Bundle::LWP
too. The current version doesn't try to install /usr/bin/HEAD unless you
specifically ask it to. When it asks if you want to install it, the
default is "n".

OK, thanks for the info. I'm still a little bit worried about this
exception case. I've been bitten by case-dependency before.

Hmmm, I found a description of Bundle::LWP in the perl docs: "This bundle
defines all reqreq modules for libwww-perl." OK... I guess there are
individual modules and bundles of related modules -- I probably want the
bundle. I guess (hope) "reqreq" is a typo.

So basically, what you're left with is, don't bother upgrading the CPAN
shell if all you want is to install LWP. The bug in LWP has been fixed,
so simply entering "install Bundle::LWP" and accepting all the defaults
will safely install it.

Hmmmm, I don't think that I have anything to add beyond LWP, but --gosh--
there are a lot of _very_ interesting modules in CPAN, and I don't want to
be afraid of/limited from using anything further because I haven't done
reasonable work at this point.

I think I'll follow your earlier suggestion, if that's ok: Install the
newest CPAN module by hand. I _hope_ that goes uneventfully!

Thanks,

Henry

(e-mail address removed) remove 'zzz'

 

[Sherm Pendley]

impressive that you have taken this level of precautions.

It's necessary for what I do. I maintain a Cocoa/Perl bridge that links
against libperl. Since 5.6 & 5.8 aren't binary compatible, I need to
keep both systems available for testing purposes, and I have only one
machine.

To think, I switched to get away from having to dual-boot between
Windows & Linux...

"By hand..." Sure, no problem. I can do that, assuming there are few or no
dependencies to resolve.

As far as I know, the CPAN.pm dependencies are "soft." That is, there
are some modules it *can* use to enhance its operation - i.e. verify
downloads with MD5 checksums, use Perl's "Archive::Tar" module instead
of making a system call to "tar", etc - but they're optional.

Actually, it's a lot less intimidating to me than
using the CPAN shell.

You can use the CPAN shell to manage the downloads only, if you'd prefer
to handle the build process yourself. For some modules this is a
requirement - for example, when installing DBD::mysql, parameters need
to be passed to "perl Makefile.PL" that tell it what user/password to
use for running its tests.

In the CPAN shell, running 'look Module::Name' will download the latest
version of the module, unpack it, and open up a subshell in the
directory where it was unpacked. You can then run the 'perl Makefile.PL;
make; make test; make install' sequence by hand.

Also, you can view a module's readme with 'readme Module::Name'.

OK, so I'll ask explicitly: Given version 'n' of a particular module is
installed on your system, and you've found new module 'm', how can one
figure out the importance--necessity-- advisability-- safety--chances of
success of installing the newer one?

Well, there are no guarantees. There's always a chance that you'll be
the first to discover a particular bug. On the other hand, a surprising
number of Perl's core developers are using Macs, so that's not very likely.

As far as the importance of upgrading goes, I tend to be conservative
and follow the "if it ain't broke, don't fix it" rule. I delay any and
all upgrades until they're truly necessary. For example, if what I'm
writing doesn't work on a client's server because they're using a newer
module, and the API has been changed, I'll install the newer version on
my machine.

The chances for installation success vary. Pure Perl modules rarely have
problems installing. Modules that provide wrappers around C libraries
can be problematic, or more accurately, compiling and installing the
libraries they wrap can be. Fink can help, but if you use it you'll
often have to pass additional parameters to Makefile.PL to help it find
the libraries you've installed - /sw/lib isn't one of the traditional
places to look for them.

If you're uncertain of success, and production scripts rely on a
particular module, you can always use the "PREFIX" option to Makefile.PL
to install the module in an out-of-the-way location, and test your
script against it by using 'use lib' to add that location to the module
search path.

Same question for the next dot revision of Perl itself.

I'm constantly amazed by the number of folks who claim to need the
latest version, but can't give a single reason beyond a vague notion
that it's "better" somehow.

The fact is, if you're just learning the language, 5.8 doesn't offer
much that you truly need. Better Unicode support is useful if you need
to process European or Asian text, and a number of standard modules have
been updated. But, hardly any changes were made to the core language,
and the changes that were made are fairly esoteric.

In short, if you're beginning to learn Perl now, then by the time you
actually need 5.8, you'll probably be running Panther anyway.

If you *do* find yourself installing a newer Perl, for whatever reason,
the one major, golden rule to follow is: Don't overwrite Apple's Perl.
Doing so leaves you no margin of safety if something goes wrong.
Configure the new one with a prefix of /opt, or /usr/local, or
/whatever, and you're golden. No matter how badly you mis-configure it -
and you will, the first few times, count on it - it won't cause any
fatal damage.

sherm--

 

[Henry]

Sherm:

Thanks for your email:

It's necessary for what I do. I maintain a Cocoa/Perl bridge that links
against libperl. Since 5.6 & 5.8 aren't binary compatible, I need to
keep both systems available for testing purposes, and I have only one
machine.

I guess that would be CamelBones...

I'm pretty sure I don't understand the uses of this technology, but I'm an
embedded systems designer; we don't usually need high-level object-oriented
stuff. We're glad if we can get the bare machine to run some instructions.

To think, I switched to get away from having to dual-boot between
Windows & Linux...

You got away from Win, which sounds like an advantage to me. The safest
execution mode for Win, I've found, is to never boot into it at all.

As far as I know, the CPAN.pm dependencies are "soft." That is, there
are some modules it *can* use to enhance its operation - i.e. verify
downloads with MD5 checksums, use Perl's "Archive::Tar" module instead
of making a system call to "tar", etc - but they're optional.

Right, that accounts for the rather indefinite language I've already seen
when I tried to get lwp.

I've managed to manually download and install the latest CPAN without any
real problem.

You can use the CPAN shell to manage the downloads only, if you'd prefer
to handle the build process yourself. For some modules this is a
requirement - for example, when installing DBD::mysql, parameters need
to be passed to "perl Makefile.PL" that tell it what user/password to
use for running its tests.

OK.

I looked for a way to ask the CPAN shell to tell me what it _would_ do, like
the "make -n" option, without actually doing anything. Couldn't find
anything. Seems like that would be helpful.

In the CPAN shell, running 'look Module::Name' will download the latest
version of the module, unpack it, and open up a subshell in the
directory where it was unpacked. You can then run the 'perl Makefile.PL;
make; make test; make install' sequence by hand.

Aha! What a great idea!

I _did_ look at the CPAN shell help, but its short description "open
subshell in these dists' directories" at a glance seemed like it would open
a CPAN subshell, not a unix subshell -- and that didn't seem very
interesting.

Also, you can view a module's readme with 'readme Module::Name'.

Thanks. I have been keeping cpan.org open and looking at the full
descriptions there.

Well, there are no guarantees. There's always a chance that you'll be
the first to discover a particular bug. On the other hand, a surprising
number of Perl's core developers are using Macs, so that's not very likely.

Sounds like a good reason to pick fully released versions, and to avoid
development releases.

I'm known for my capability to find obscure bugs, so I need to be especially
careful.

As far as the importance of upgrading goes, I tend to be conservative
and follow the "if it ain't broke, don't fix it" rule. I delay any and
all upgrades until they're truly necessary. For example, if what I'm
writing doesn't work on a client's server because they're using a newer
module, and the API has been changed, I'll install the newer version on
my machine.

Right. Similar reason: I'm delaying upgrading to Panther.

The chances for installation success vary. Pure Perl modules rarely have
problems installing. Modules that provide wrappers around C libraries
can be problematic, or more accurately, compiling and installing the
libraries they wrap can be. Fink can help, but if you use it you'll
often have to pass additional parameters to Makefile.PL to help it find
the libraries you've installed - /sw/lib isn't one of the traditional
places to look for them.

I think I'll stick with the mainline, standard modules as much as possible.

If you're uncertain of success, and production scripts rely on a
particular module, you can always use the "PREFIX" option to Makefile.PL
to install the module in an out-of-the-way location, and test your
script against it by using 'use lib' to add that location to the module
search path.

I started to do that, then forgot.

But what I'm working with right now is pretty reliable -- I have to believe
that updating the CPAN shell, adding Net::FTP, LWP, and similar have to be
pretty robust.

If I feel the need to try 'sleazebag.pm' I'll definitely install it as far
away as possible from the standard stuff. (Maybe on one of my NT boxes.)

I'm constantly amazed by the number of folks who claim to need the
latest version, but can't give a single reason beyond a vague notion
that it's "better" somehow.

If we're talking about, say, MacOS, I think there's definitely a fall-off in
support for version 'n' when version 'n+1' is in general release. It's
also true, for commercial packages, that marketing departments' major task
to make you feel at least vaguely uneasy about using an older version.

These motivations might be less significant for a product like Perl. For
one --as far as I know-- no marketing department.

The fact is, if you're just learning the language, 5.8 doesn't offer
much that you truly need. Better Unicode support is useful if you need
to process European or Asian text, and a number of standard modules have
been updated. But, hardly any changes were made to the core language,
and the changes that were made are fairly esoteric.

'Nuf said; I did the right thing to stay with the existing 5.6.

In short, if you're beginning to learn Perl now, then by the time you
actually need 5.8, you'll probably be running Panther anyway.
Right.

If you *do* find yourself installing a newer Perl, for whatever reason,
the one major, golden rule to follow is: Don't overwrite Apple's Perl.
Doing so leaves you no margin of safety if something goes wrong.
Configure the new one with a prefix of /opt, or /usr/local, or
/whatever, and you're golden. No matter how badly you mis-configure it -
and you will, the first few times, count on it - it won't cause any
fatal damage.

You're preaching to the choir. I live in fear of losing something that
works tolerably well and spending days trying to recover that functionality.
I have a bad feeling that messing with the distributed version would lead
inevitably to a complete re-install of the OS. --Maybe that's a carry-over
from working in NT, where even minor glitches routinely require re-installs.

To bring you up to date: I've got LWP installed and I can at least do "use
LWP" without error. I guess I won't need to do the wget hack after all!
Thanks for your handholding!

Thanks,

Henry

(e-mail address removed) remove 'zzz'