LWP install MacOS X

Discussion in 'Perl Misc' started by Henry, Dec 11, 2003.

  1. Henry

    Henry Guest

    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::parser, 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

    remove 'zzz'
    Henry, Dec 11, 2003
    #1
    1. Advertising

  2. Henry wrote:

    > OK, it's time to go CPAN. Download LWP. No problem. But it won't install
    > unless URI, HTML::parser, 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--
    Sherm Pendley, Dec 12, 2003
    #2
    1. Advertising

  3. Henry

    Henry Guest

    Sherm:

    Thanks for your response on this thread:

    in article NBaCb.13056$, Sherm Pendley at
    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::parser, 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--
    Henry, Dec 12, 2003
    #3
  4. 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
    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--
    Sherm Pendley, Dec 12, 2003
    #4
  5. Henry

    Henry Guest

    Sherm:

    Thanks for your response on this thread:

    in article OqdCb.4$, Sherm Pendley at
    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
    > 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

    remove 'zzz'

    >
    > sherm--
    Henry, Dec 12, 2003
    #5
  6. 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--
    Sherm Pendley, Dec 12, 2003
    #6
  7. Henry

    Henry Guest

    Sherm:

    Thanks for your response on this thread:

    in article 7CqCb.315$, Sherm Pendley at
    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

    remove 'zzz'

    >
    > sherm--
    Henry, Dec 12, 2003
    #7
  8. 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--
    Sherm Pendley, Dec 13, 2003
    #8
  9. Henry

    Henry Guest

    Sherm:

    Thanks for your response on this thread:

    in article giuCb.431$, Sherm Pendley at
    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

    remove 'zzz'



    >
    > sherm--
    Henry, Dec 13, 2003
    #9
  10. 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--
    Sherm Pendley, Dec 13, 2003
    #10
  11. Henry

    Henry Guest

    Sherm:

    Thanks for your email:

    in article d6LCb.734$, Sherm Pendley at
    wrote on 12/13/03 1:00 PM:

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


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


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


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


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


    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

    remove 'zzz'
    >
    > sherm--
    Henry, Dec 13, 2003
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. silverburgh

    Install Python 3.0 dmg to macos 10.5

    silverburgh, May 6, 2009, in forum: Python
    Replies:
    1
    Views:
    258
    Diez B. Roggisch
    May 6, 2009
  2. phantasm
    Replies:
    2
    Views:
    764
    phantasm
    Mar 11, 2010
  3. Yvon Thoraval

    Fink install of Ruby under MacOS X.2.6

    Yvon Thoraval, Sep 21, 2003, in forum: Ruby
    Replies:
    0
    Views:
    113
    Yvon Thoraval
    Sep 21, 2003
  4. Phrogz

    Can't Install on MacOS X

    Phrogz, Feb 18, 2005, in forum: Ruby
    Replies:
    1
    Views:
    88
    Phrogz
    Feb 18, 2005
  5. pete boardman

    How to install something on MacOS X?

    pete boardman, Nov 9, 2005, in forum: Ruby
    Replies:
    12
    Views:
    179
    Michael Granger
    Nov 30, 2005
Loading...

Share This Page