Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: What sets Perl back

by zentara (Archbishop)
on Dec 11, 2005 at 11:44 UTC ( #515825=note: print w/replies, xml ) Need Help??


in reply to What sets Perl back

I still don't even use the cpan module to install. I do it the old-fashioned way, download the tarball, perl Makefile.PL, make, su root, make install. Is that so hard?

I do it that way, because I want to see what I'm getting, read any README's, look at example scripts, and generally be sure everything is proper.

I don't want to start any arguments, but I can't bring myself to run anything online as root, which does an automatic install. I want to look at it first.

The one thing that does irritate me, is "dependencies". I start screaming when I need to track through 3( or more ) dependency levels, when trying to install a module. What I would like to see are more "bundles", which let you get everything needed in one download, and prompts you if it detects newer versions, etc.


I'm not really a human, but I play one on earth. flash japh

Replies are listed 'Best First'.
Re^2: What sets Perl back
by thor (Priest) on Dec 11, 2005 at 17:26 UTC
    Might I suggest CPANPLUS? The tool that it comes with (cpanp) has a command that downloads whatever module you've asked for and drops you into a shell in the directory where it untarred it. However, it's a lot more powerful than that. You can run cpanp as yourself and have it use sudo for the "make install". This way, you can be sure that the only thing that is happening as root is the install, nothing more. As stated elsewhere in this thread, it'll also track dependencies for you, so that's a bounus.

    thor

    The only easy day was yesterday

      Yeah, I should check that out. :-) But it's hard for me to give up on the old-fashioned way, when it works so well. Old dogs...new tricks. :-)

      I'm not really a human, but I play one on earth. flash japh
Re^2: What sets Perl back
by BrowserUk (Pope) on Dec 11, 2005 at 13:12 UTC

    I'm the same, using CPAN drives me nuts. First it insists on downloading an ancient version of nmake.exe from the net, when there is already a much more up to date version on my system, simple because I keep my executables where they are supposed to be (eg. the compilers bin directory in this case), not where cpan thinks it belongs. It's in my path. Just use it already.

    But before we get to that, it insists on downloading some damn index from cpan that takes forever. I wouldn't mind, but the next time I use it, it then wants to verify if it's copy of this mysterious dratted index is up to date. which takes longer than downloading it did, and it never is, so it goes ahead and downloads it again anyway.

    Then, if the compiliation fails, which always seems to on Win32, I've no idea what it has succeded in doing and what not, because it hides all the output from me.

    Like you, I prefer to download the tarballs (or sometimes just the .pms for simple one-file perl-only modules), but the dependancies are a pain. Maybe we should write a script that just builds a list of dependancies by querying cpan?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Yeah, I hear your pain, some of it is shared by humble myself too.

      What I'd love to see is some level of integration into package management, like in my case, apt-get.

      Another annoyance is that CPAN:: doesn't have any uninstall/remove capabilities, or at least not something trivial like install <module> is.

      CPAN is a great resource, but making it more accessible would help a lot in code reuse. There are some modules which depend on half of CPAN and installing such monsters are hard and annoying. When the compilation fails somewhere I have to figure which debian packages to install, then retry. Not really userfriendly.

      First it insists on downloading an ancient version of nmake.exe from the net, when there is already a much more up to date version on my system, simple because I keep my executables where they are supposed to be (eg. the compilers bin directory in this case), not where cpan thinks it belongs. It's in my path. Just use it already.

      Thats very strange. I've never observed CPAN do anything like that, either with hand built perls or with AS builds. When I config CPAN it finds the correct nmake in my path, and uses it thereafter. I've never seen CPAN download nmake.exe, ever.

      Then, if the compiliation fails, which always seems to on Win32, I've no idea what it has succeded in doing and what not, because it hides all the output from me.

      Again thats a strange description when I see a failed build I see all the gory details, unless its a make test failure, in which case it isn't CPAN in the way, but Test::Harness, which usually means you need to look NAME and then nmake test TEST_VERBOSE=1 to see whats failed.

      ---
      $world=~s/war/peace/g

        Maybe the nmake thing was just one particular package I tried to use CPAN.pm for that did that (Pugs?). I haven't attempted to use for so long that I don't remember for sure. I've had trouble using it on every build I've ever installed.

        Do you get this lot every time you run it?


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
      Add to this the unfathomable inability of CPAN.pm to download the MIRRORED.BY file. I've known CPAN.pm go through almost my whole list of mirrors failing to download the damned thing and when I've checked the URL the file is right there on the FTP server where it ought to be. Why is this allowed to go on? I can't be the only one going through this nonesense. As I said at the start this kind of thing is setting back the adoption of Perl. Developers who are not fully committed to doing whatever it takes to get Perl modules installed are going to eventually use something else. Perl will only have itself to blame if it becomes marginalised.

        I have that problem with every new MacOS install, but the problem isn't with Perl, or even the OS ... it's my firewall. CPAN.pm tries to use Net::FTP, which MacOS has installed -- but it doesn't have a libnet.cfg file, and I'm behind a firewall which requires me to use passive FTP.

        In cases like this, it has nothing to do with the commitment of Perl devlopers, or the OS, or anyone else, but a knowledge of what my environment is. Every environment is different, and it is impossible for the developers to plan for every last possible permutation of configuration variables. They can get it so that things work most of the time, but once in a while, you actually have to look at the README files, and/or understand what the error messages are.

        I personally find that you can often get help with problems by asking for it -- if you present it as a general bitch about the community, you are much less likely to get the problem that you're having resolved. If you actually want to get the problem fixed, I would assume that you would phrase it slightly differently than just general complaining. It might feel good to vent, but I find it normally feels even better to get it fixed, and behind you.

Re^2: What sets Perl back
by sub_chick (Hermit) on Dec 11, 2005 at 20:31 UTC
    The one thing that does irritate me, is "dependencies". I start screaming when I need to track through 3( or more ) dependency levels, when trying to install a module. What I would like to see are more "bundles", which let you get everything needed in one download, and prompts you if it detects newer versions, etc.

    This is something I would be more interested in seeing. I have only been able to install one Module since i started perl about a month ago and that was Net::RawIP. Eversince then, I get this error:
    530 Sorry, the maximum number of clients (2) from your host are alread +y connected. 421 Service not available, remote server has closed connection. Login failed. Local directory now /root/.cpan/sources/modules Not connected. Not connected. Not connected. Not connected. Not connected. Not connected. Not connected. Bad luck... Still failed! Can't access URL ftp://cpan.netnitco.net/pub/mirrors/CPAN/modules/03mo +dlist.data.gz.
    when i know for a fact that the server is not full everytime I try to install a module via CPAN. Seeing more bundled modules with dependencies in tow would ease the troubles of installing modules manually.

    "Es gibt mehr zu Leben als Bücher, kennen Sie. Aber nicht viel mehr " -(Der Smiths)
      That's not a server full error, that's a "you're hitting me too much" error, try a different mirror?

      --
      In Bob We Trust, All Others Bring Data.

Re^2: What sets Perl back
by gunzip (Monk) on Dec 11, 2005 at 12:52 UTC
    But dependencies are precisely why the the CPAN module exists. Ever tried installing something like Catalyst by hand? Take a week off work!
    A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://515825]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (6)
As of 2021-01-16 18:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?