Perl is still held back, in my opinion, by the precarious business of installing CPAN modules. Something needs to be done about it...

Option #1 -- don't install modules. Problem solved.

Option #2 -- report the bug. This post doesn't count.

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.

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

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

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.

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.
[download]

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.

But dependencies are precisely why the the CPAN module exists. Ever tried installing something like Catalyst by hand? Take a week off work!

I haven't tried installing modules under those two OSes, but I can say that with SuSE Linux I've had no problems. Just type 'cpan' search for the module, and install.

Things may be different on other operating systems, but I'd also consider the possibility that it could be something else - perhaps having certain assumptions that aren't quite accurate, for example.

Ironically, I've always had problems with installing PHP...

The comment below is not an attack against gunzip but rather a general call for opinions...

I'm afraid I find module errors well over my head and don't think your average Perl developer should have to understand such internals.

Am I the only one that finds this snippet disturbing? Shouldn't an "average <language> developer" understand the environment he/she is working in?

IMNSHO, one of the richest tools at the disposal of the Perl community is, precisely, CPAN. I think an APD should understand how this works and how to use this tool.

Really, I don't mean this to be a rant. I'm just curious about what the rest thinks.

Should an 'average' Perl programmer also have to be a cross-platform (Unix + their platform) C guru; makefile expert; XS wiz; and fully versed in the machinations of ExtUtils::MakeMaker, Test::Harness, et al. ?

---

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.

... guru ... expert ... wiz ... fully versed ...

Well BrowserUK, I think there's a wide gap between the terms you used and the concept of "understanding the platform" that caused my prior node.

Perhaps my concept of "average Perl programmer" is not the average:-)

However, I think that given the typical uses we see for Perl, it does not hurt to understand a little better the context in which your code exists and how is it tied with the rest of the platform.

Best regards

-lem, but some call me fokat

Firstly I'd suggest that almost all Linux, Unix, or *BSD variants should be able to install directly from CPAN. However many people dislike that if they have a packaging system in place upon their host.

It can get problematic if you, say, install Perl modules from CPAN but your distribution has a perl upgrade and breaks them all. In that case using the packages provided for your distributions may be the best bet. (That is what I recommend anyway.)

So from that point of view I find using Debian nice and simple. Many modules are packaged as .deb binary files, with a nice naming convention so they are easy to find.

e.g. HTML::Template -> libhtml-template-perl, CGI::Application -> libcgi-application-perl.

For the modules which aren't available as Debian packages you can easily create them - just by using a wrapper tool around CPAN's scripts:

• Creating Debian binary packages of Perl modules

The short version is:

apt-get install dh-make-perl build-essential
dh-make-perl --build --cpan HTML::Template
[download]

Steve
--

Ya know, I've heard a couple of people complain about this recently, yet I can't even remember the last time I've had a (serious) problem with cpan. I just open a terminal, type "cpan module" and it downloads and installs almost instantly. No fuss, no muss, extremely easy.

If you want quality assurance, let me suggest you try ActiveState Perl on your existing platforms. They include the Perl Package Manager (PPM) that installs prepackaged binaries from the ASPN module repository (and other repositories as well). There is a slight delay from CPAN, but they automatically update to the latest versions within a week or so -- assuming that they pass an automated build process.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

My sentiments exactly. Although I rarely have any problems when installing from CPAN those that I do have plauge me incessantly.

My major issue with CPAN is the lack of good system to track installed modules & associated files for the purposes of reporting on installed modules and removing them completely when they are no longer needed. I've seen various attempts at doing this properly but none of them have appeared to work as well as apt on my Debian boxen.

Cheers,

Matt

P.S. If there are those out there that think they have a fool-proof method of tracking and removing modules & *all* associated files, I'd be more than glad if you spoke out now.

The problem I forsee with using packages, be they .rpm or .deb, is that they're probably not up to date. With CPAN I can get hold of a new release as soon as it becomes available.

Ah, so you want the absolute latest thing, but you also want it to be pre-compiled and fully-tested for your operating system. Now I see why you're having trouble.

My "fear" of CPAN modules comes in two forms, 1) the aforementioned installation woes (whether on my Mac OS or web server), and once installed 2) understanding how to use them. More often than not, the documentation is lacking in fundamentals and examples--so much is implied or assumed.

I'm not a full-time programmer, but use Perl for my web apps. I suppose if I were a trained programmer, or was doing it full-time, the learning curve might be shorter. It takes me so long to figure out how to use a lot of modules, scouring the web for examples and explanations. It seems like half my questions on PMs relate to module use. And most questions would be unnecessary if the documentation where geared to the less experienced. Wheres the CPAN Modules for Dummies book?

Anyway, I have made a pact with myself to write or add to a review/tutorial once I understand the basics of a module.

Most good programmers write some really crappy documentation. And even if they do go to the trouble of writing documentation, there's the chance that it's not kept in sync with the actual code.

I would love to see 'Writing Documentation 101' taught as part of a computer science degree, but even if the programmer could manage to write something, it goes against just about everything most programmers hold valuable -- saving time.

We write tools to save ourselves time ... often, it's write once, and forget about it. Until you start getting into something that's cyclic in nature, with a rather long period (eg, you only have to do it once a year or so), you think to yourself that there's no point it documenting things. Come the third or fouth time of trying to remember what you were doing, you start to appreciate how important the documentation is ... but even then, you're writing documentation for yourself, and not for others.

Have you ever had a class, where the teacher wrote the book? If the teacher makes no sense in class, you read the book, and realize that it's all been presented in the same way that makes no sense to you. The only benefit of writing documentation is in forcing the programmer to think about things in a way to present it clearly.

Personally, I've been writing my interfaces before I write the programs lately -- you can write the general user documentation, make sure it plugs in with other programs that might make use of it, and then fill in the blanks. But I've gotten stung a few times by minor changes that I forgot to express in the docs, and when I look at it 6 months later, I have to remember why I made changes that broke the docs (I know, anything in the docs should be expressed as a test, so that the errors will show up when I run the text suite, and I need to set up the test suites to generate reports nightly, in case something gets committed by someone else to the repository)

Right ... so as I've gone off on a tangent -- what's the right solution? Hopefully, get someone else to write the docs, or to ask you enough questions early on, that you start answering them, and recording them as documentation. Writing the docs yourself does no good unless you then get someone to use the docs, and essentially test them to make sure that they don't confuse people.

Most good programmers write some really crappy documentation.

[snip]

but even if the programmer could manage to write something, it goes against just about everything most programmers hold valuable -- saving time.

It's, of course, actually a time saver in the long run to write good docs.

• Good docs make it easier for *others* (co-workers? folks on the qa team? do-gooders in the free software community?) to work on your code rather than you having to do it yourself,
• Good docs save you time when you need to re-familiarize yourself with your own code that you may not've touched in a while

Personally, the first thing I look for in a free software project is good docs. If the docs are good, you can always write tests and fix or update the code as-needed. If the code is ok, but the docs aren't good, the software is (in the long run) only useful to those who are willing to pore over it and try to figure out what it's supposed to be doing.