Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > LWP install MacOS X

Reply
Thread Tools

LWP install MacOS X

 
 
Henry
Guest
Posts: n/a
 
      12-11-2003
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

http://www.velocityreviews.com/forums/(E-Mail Removed) remove 'zzz'

 
Reply With Quote
 
 
 
 
Sherm Pendley
Guest
Posts: n/a
 
      12-12-2003
Henry wrote:

> 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--
 
Reply With Quote
 
 
 
 
Henry
Guest
Posts: n/a
 
      12-12-2003
Sherm:

Thanks for your response on this thread:

in article NBaCb.13056$(E-Mail Removed), Sherm Pendley at
(E-Mail Removed) wrote on 12/11/03 7:28 PM:

> Henry wrote:
>
>> 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.


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.
>
>> "... 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.


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!)
>
>> , 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.


"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--


 
Reply With Quote
 
Sherm Pendley
Guest
Posts: n/a
 
      12-12-2003
Henry wrote:

> $%*$%!@@$!$, 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 Removed)
mailing list - you can (un)subscribe and/or search the archives at
<http://lists.perl.org>.

> 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--
 
Reply With Quote
 
Henry
Guest
Posts: n/a
 
      12-12-2003
Sherm:

Thanks for your response on this thread:

in article OqdCb.4$(E-Mail Removed), Sherm Pendley at
(E-Mail Removed) wrote on 12/11/03 10:41 PM:

> Henry wrote:
>
>> $%*$%!@@$!$, 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.


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.
>
>> 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.


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.

>
>> 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 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.
>
>> 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.


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 Removed) remove 'zzz'

>
> sherm--


 
Reply With Quote
 
Sherm Pendley
Guest
Posts: n/a
 
      12-12-2003
Henry wrote:

>>That reminds me of another tip - I always go into Terminal.app's
>>preferences, and set the scrollback buffer to "unlimited."


> 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--
 
Reply With Quote
 
Henry
Guest
Posts: n/a
 
      12-12-2003
Sherm:

Thanks for your response on this thread:

in article 7CqCb.315$(E-Mail Removed), Sherm Pendley at
(E-Mail Removed) wrote on 12/12/03 1:41 PM:

> Henry wrote:
>
>>> That reminds me of another tip - I always go into Terminal.app's
>>> preferences, and set the scrollback buffer to "unlimited."

>
>> 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.


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.
>
>> 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.


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.

>
>> 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.


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 Removed) remove 'zzz'

>
> sherm--


 
Reply With Quote
 
Sherm Pendley
Guest
Posts: n/a
 
      12-13-2003
Henry wrote:

> 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.

>>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.


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--
 
Reply With Quote
 
Henry
Guest
Posts: n/a
 
      12-13-2003
Sherm:

Thanks for your response on this thread:

in article giuCb.431$(E-Mail Removed), Sherm Pendley at
(E-Mail Removed) wrote on 12/12/03 5:53 PM:

> Henry wrote:
>
>> 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.


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.
>
>>> 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.

>
> 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 Removed) remove 'zzz'



>
> sherm--


 
Reply With Quote
 
Sherm Pendley
Guest
Posts: n/a
 
      12-13-2003
Henry wrote:

> 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--
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can't install PIL on MacOS X Leopard phantasm Python 2 03-11-2010 12:43 AM
Install Python 3.0 dmg to macos 10.5 silverburgh Python 1 05-06-2009 12:07 PM
How to install something on MacOS X? pete boardman Ruby 12 11-30-2005 10:50 PM
Can't Install on MacOS X Phrogz Ruby 1 02-18-2005 04:57 AM
Fink install of Ruby under MacOS X.2.6 Yvon Thoraval Ruby 0 09-21-2003 07:32 AM



Advertisments