47 thoughts on “CPAN FAIL”

1. I wonder if the recent “fall of Perl” (e.g. this article, which I think is not wildly off base) has more to do with this.

   I don’t use mac – and on Ubuntu I have no such CPAN problems, but that’s not surprising. (By the way, you should probably include a Module::Build version prereq — I’m suspecting that the default Ubuntu version of Module::Build is out of date?):

   Checking whether your kit is complete…
   Looks good
   Checking prerequisites…
   Looks good
   Creating new ‘Build’ script for ‘Metaweb’ version ’0.05′
   CPAN: Module::Build loaded ok (v0.280801)
   No action ‘-j3′ defined, try running the ‘help’ action.
   SKUD/Metaweb-0.05.tar.gz
   ./Build -j3 — NOT OK
   Running Build test
   Can’t test without successful make
   Running Build install
   Make had returned bad status, install seems impossible

2. … and i still have that error once Module::Build is upgraded to 0.33, so maybe not the issue.

   of course, this is not to the point of ‘CPAN should be easy on OSX’, with which I totally agree.

3. Having just had to rebuild my dev environment after upgrading to snow leopard, which has a broken perl included by default I’m rather sympathetic.

   Now that perl 5.10 is relocatable, and the 5.10.0 attribs bug is fixed in 5.10.1, a nice bootstrap script to set up a hand rolled perl in your home directory, optionally with local::lib, and minicpan, that does all the configuring of env vars and login scripts would be very nice. This would be roughly equivalent to strawberry perl for os x.

   Better rather than just a simple –verbose flag, to dump all output to /tmp/cpan.log, and tee it to stdout if –verbose is true by the way.

4. @Jeremy: I actually have my own opinions on the State of Perl, but that’s a whole nother blog post.

   I find Perl dev and CPAN installations on Linux (Debian/Ubuntu specifically) easy compared to OSX, but a while back when I was working on a web host where I didn’t have root, I found a lot of the same problems I describe in this blog post.

   Perl’s still pretty good for scripting using just the core libraries, and there are some powerful frameworks for doing Serious Big Development if you are experienced and disciplined, but IMHO everything in between is an enormous mess.

5. The part of this that spoke to me the most was “Luckily I happen to know that ‘the developer tools’ means XCode”, which isn’t so much a CPAN fail as an Apple fail. This was drilled home to me recently when the professor I work for upgraded to Snow Leopard. The first time he tried to run make and it didn’t work, he handed the laptop to me. I saw that make wasn’t installed, installed Xcode Tools, and now he has the one small thing he needed, along with a whole bunch of big things he’ll never need. While I was doing it, though, he asked a great question: “If you weren’t here, how could I have found out that that’s what I needed to do?” I have no idea! He’s a computer scientist who teaches programming languages; it’s not as though he’s technology-averse. I guess they don’t expect anyone who has reason to use make to not already have Xcode installed, but surely there are many, many people in that boat — especially if you apparently lose Xcode every time you upgrade the OS.)

6. Whenever I’ve done serious Perl development, I’ve always come up with a custom build system that involved pre-fetching specific versions of modules and a way to cache the source locally so that you don’t wind up in CPAN hell when trying to rebuild a version of something. And I always package built versions of modules with the installed version of whatever it is that’s being written. That’s quite a lot of yak shaving to essentially dodge the CPAN system entirely before you even start a project, of course. Not conducive to just getting in there and writing some code.

   I’m dubious about how fixable the state of CPAN is – the randomness of dependency version hell, the inability to actually have a useful snapshot of the module-versions you’re actually depending on, the randomness of dependencies on specific versions of gnumake and gnuhell generally, all that needed to be accounted for properly at the start… and it wasn’t.

   You’d have to throw it all out and start again with a better approach – one that takes into account module version interdependencies, external dependencies, cross-platform fu and similar build issues.

   Python is less messy in that respect by quite a lot. Less convenient if you need to go outside the core libraries, but fortunately that’s actually fairly rarely needed, because the Python core library set is quite a bit better maintained, and is maintained with the intent of being covering quite a lot of commonly needed stuff. And even when you do need to go outside core, the build system is not as frequently screwed by dependency hell.

   Not sure what the state of Ruby is in that space.

7. A minor note, perhaps, but the proper command is just “cpan JSON”, not “cpan install JSON”. Saying “cpan install …” actually tries to install the “install” module from the junoscript distribution, which brings in lots of dependencies like Date::Manip.

8. Oh yeah. The other alternative for Mac OS is to only use modules available as fink or macports packages… Which has its own set of problems in terms of delays and module availability.

9. @Skud: local::lib fixes the cpan without root problems elegantly to the point where a developer should never really need to touch the system perl.

   @Thorfi: you make it sound like large projects with interdependencies are impossible in perl. This really is not true.

10. @Skud I can empathize. I’m happy I’m not the only one who’s felt that way, going through the same thing. Sometimes I wondered if I was just being picky.

    @Thorfi Ruby is somewhat better, but it seems that all three languages mentioned so far have a much bigger issue — new versions of the language, and not all modules support them. I think Perl is doing better on that front than the others, with most of the modules I use frequently being totally 5.10-clean. That’s definitely not the case with Ruby, where a good number of very useful modules (and the vast majority that aren’t pure Ruby) still can’t handle 1.9.

11. First of all that “why perl lost it article” is just … silly. He’s complaining about Perl 5 and proving his points with links to Perl 6? You can probably stop reading at that point.

    I’m not sure why there’s not an obvious way to install the latest Perl on OSX, Kirrily, but one reason might be, the system Perl does all kinds of key things in the background of OS X and Apple don’t want you messing with it.

    One idea is to use MacPorts or Fink to install another perl — then you can have whatever version(s) you want at /sw/bin/perl or /opt/local/bin/perl and leave /usr/bin/perl alone.

12. @lindsey Weirdly enough, I helped out a Classics professor in a cafe courtyard in Santa Cruz who had exactly the same problem. I overheard him asking someone who didn’t know, so I just kinda butted in and told him. Then I listened in on an introductory Latin tutorial while I knitted. It was a lovely afternoon — but yeah, the whole OSX/make/XCode thing is pretty ridiculous.

    @dagolden Ah, that explains quite a bit! As I said, it’s been a while — I guess I was conflating it with “perl -MCPAN -e ‘install JSON’”.

    @thorfi yup, most major professional Perl work I’ve done has had some kind of complicated packaging/deploy system to avoid having to deal with CPAN too often.

    @kd How is a relatively new developer meant to know about local::lib? If that’s best practice, why isn’t in the Perl FAQ? As for big projects with multi-person teams and complicated interdependencies — I’ve never worked on one that deploys to production using CPAN. Preferably I prefer to package the exact versions I need, along with my own app, using dpkg and use Debian/Ubuntu’s packaging system to manage dependencies and stuff. The other option that I’ve seen work OK (especially where the corporate environment is a bit less open sourcey) is to put all the CPAN dependencies right into your own version control system.

    @kjw Good to hear a Ruby perspective. OTOH, with Perl I often find the reverse: you need a recent version of a CPAN module, but (often for no particularly good reason) it doesn’t run with anything except the latest Perl. This drove me nuts a while back when I was working somewhere that was languishing on Perl 5.6 when Perl had moved on to 5.8.4 or so.

13. @ambrose Is that best practice, or even a commonly used option? If so, why isn’t it mentioned on perl.org or perl.com or in the Perl FAQ?

14. OS X is by far the worst platform for Perl, which I find bizarre since so many good Perl people are on OS X.

15. I should also add that, bizarely, almost every conference or Perl event I go to, I have people asking when I’ll be releasing Strawberry Perl for OS X. Clearly there’s some recognition of the problem, it’s just that nobody seems to do anything about it.

16. Oh, and also, I wasn’t aware that junoscript bug was still a problem anywhere, so I’ve just taken over primary maintainership on the “install” namespace. Since I don’t have anything sitting on that namespace, hopefully you should now just get a “unknown module install” error.

17. To your list I would add “Fail early” – there is quite a lot of prerequisites that could in theory be checked ahead of time – for example external dependencies: http://perlalchemy.blogspot.com/2009/09/what-really-fails-in-installation.html (a related blog post: http://perlalchemy.blogspot.com/2009/12/external-dependencies-once-again.html ) and the perl version as well.

18. Only very old cpan(1) will try to install junoscript. When we discovered that ‘install.pm’ was indexed as part of junoscript, *and* people were typing random commands to cpan(1) without ever reading the docs, I nerfed “install” and ignored it (despite it never being a legal command for that tool).

19. @Skud There was a recent Perl Foundation grant to improve learn.perl.org. The content hasn’t gone live, but it includes an intro to setting up CPAN including things like local::lib.

    @Skud Also, for what it’s worth, in coordination with CPAN admins like @Alias, I’ve uploaded a dummy install.pm so the junoscript problem won’t bother people again.

20. @skud -

    “As for big projects with multi-person teams and complicated interdependencies — I’ve never worked on one that deploys to production using CPAN.”

    - that would be the BBC, who do precisely that. Did I ever lament to you about developers who decide to use cool module of the week and leave it to the sysadmins, installing it on the production systems, to discover it pulls in over 1500 modules from CPAN?

    (Now in an all-Java shop. Not sure this is an improvement.)

21. @Jeremy K Just as an aside, the “Why Perl Lost It” article is a troll of truly impressive proportions. I say this because I work with the guy who does it. He is indeed a huge anti-Perl zealot (which I don’t get, why not be Pro-whatever-your-doing instead?) but you’ll note at the end of that post some strange links. He’s trying to get google juice and to do that he combined it with a troll he knew the Perl community would bite at. While he definately doesn’t like Perl (which is fine) he intentially muddied the waters to make more people yell and link to him.

    To Perl on OSX: yeah. Generally not fun. I had a hell of a time installing Padre initially and I was using macports perl5.10 (which in turn installed cpan5.10 to distinguish it from the system perl etc). Snow Leopard does come with 5.10.0 which made things easier. When I upgraded, I just wiped the system completely. It’s to the point where I just edit my files on my iMac and test solely on the server (not the production server though!). I don’t know if OSX actually uses anything in Perl so I wish they’d just not pacakage it at all so I could do a custom install… but I think make should be a default install, not “install our IDE in order to get your toolchain”. Perl.org should definately reflect this better (that being said, new site is WAY better these days).

22. I fell foul of the lack of make (and thus Xcode) after upgrading my MBP to Snow Leopard. I curse at Apple more than I do Perl, although I totally agree CPAN should bail on lack of working make.

23. apologies for posting the “known troll” article. (obviously, *I* didn’t know; I also didn’t follow his links which was irresponsible.)

    I’m a long-term dedicated Perl user myself — and I think it will remain my tool-of-choice for the glue/plumbing/data-munging tasks that I usually hate; it’s still the best choice for me — if only because I’ve been coding in Perl for ten years.

    The sentiment that feels basically right to me from Mr. Troll is that I haven’t felt like the community’s investment in Perl6 has really taken off in the ways that Ruby and Python have invested in newer versions and powerful design techniques.

    In particular, (1) the ‘yield’ construction on iterator methods, and (2) objects in general are neither one yet first-order notions in Perl, and though I use classes and subroutine-closure iterators all the time, I feel like it’s hard to write these in understandable ways such that other users grasp them in Perl the way they are immediately graspable in (say) Python and Ruby.

24. @skud: a new developer will find out about local::lib being recommended if they read my Catalyst book ;) And elsewhere, as noted by @dagolden

    @Dave: the perl on osx problems pop up in various places. Spaces in directories can be a problem in some circumstances, and the snow leopard perl has an important bug that makes it useless for Catalyst development. So if you want to do catalyst development at the moment the best solution is to hand roll a perl 5.10.1 into your home directory.

    @Jeremy: there’s a lot of to and fro-ing going on in the perl community at the moment, with lots of perl 6 features being stolen ^W borrowed back into perl 5, especially via Moose and Devel::Declare.

25. @brian “very old” as in “was the most up to date available 3-4 months ago on Macs.” That might be years old in Perl time, but is still out there in the wild — very much so.

    Typing “cpan install” is probably the sort of thinko that only people who used “perl -MCPAN -e ‘install Foo’” would make — so I agree that’s my fault, but I’m glad to hear cpan is catching it now, because I’d be surprised if I was the only one to make that mistake.

26. The fix I describe is a couple of years old. The Changes file shows that I released this fix on November 1, 2006, and it was in the CPAN-1.90 released on April 7, 2007. I developed it on a Mac, and it’s always be available on a Mac just like most other CPAN modules. This isn’t a Mac problem.

    It’s also not a Perl problem. When you use old version of tools, you get old bugs. Not to be too much of a jerk about this, but I’m working really hard to make this situation better and you’re spreading FUD about my work. I accept responsibility when I make a mistake, but three years after I fixed this problem I don’t expect to keep catching flak over it, especially from someone who’s supposed to know how to develop and work with a community.

    Not only that, since I’m also a PAUSE admin I have to catch the flak there too as the other admins scramble to reconfigure a couple of distributions. There really is a group of us trying to make this work out for everyone. I don’t expect lavish praise or even a thank you. I do expect not to be slagged for it though.

    Please, before you go off ranting on things, check your facts. When the lead developer of the tool corrects you, don’t make up even more stuff to defend yourself. You impunge my hard work when you disrespect my effort and attentiveness.

27. @brian Perhaps I did not phrase what I said clearly. I didn’t mean to say you’re wrong about there being newer versions available in the sense that one could get them if one knew about them, but more that the OSX 10.5, which is not so ancient (10.6 was released in September), didn’t come with anything that modern. So I guess I meant “available” in the sense of “available in the OS by default”, and I apologise for my lack of clarity.

    I didn’t intend to impugn your work as a module maintainer, but more look at the culture of the Perl community as a whole, which (IMHO) is not very good about thinking “what would this experience be like for someone who hasn’t been doing this for umpty years”. I’ve been just as guilty of it myself when I have been immersed in Perl and using it daily. It was only when I took a longish break, and came back kind of rusty and out of practice, that I realised just how high a level of skill and knowledge is needed (and how assiduously you need to stay on top of keeping everything upgraded) to be able to install and use CPAN modules, which we (i.e. the Perl community) tell people are a big selling point.

28. @Skud For what it’s worth, I think the greatest problem in many OSS communities is resistance to making things discoverable to people new to the community. “Oh, didn’t you know about $foo?” after the fact is considered an adequate alternative to discoverability. My observation is that this is most pronounced in older communities, and Perl’s is pretty old. I guess that goes for most languages. That’s one of the reasons I avoid direct contact with most programming communities these days.

    I don’t think the situation you describe in your original post is a Perl problem — I think it’s an Apple problem in some senses, and a Perl *distribution* problem. Apple seems to enjoy breaking default language installs in “interesting” ways, and I doubt they’ll stop it any time soon. On the other hand, a solution may be on the horizon as distributions like Strawberry Perl get more penetration. With some luck, companies like Apple will choose one of the “standard” distributions (such as Strawberry) and publicise the fact, so when one has trouble it’s easy to figure out where to look for answers to distribution-specific problems.

    Alternatively, Apple could embed their “broken-but-needs-to-be-for-critical-system-crap” version of Perl a little deeper and provide a separate, standardised install of Perl for all other uses.

29. I don’t think you get it. You didn’t even try. You seem to expect someone to come to your keyboard and upgrade things for you. Instead, you should think “I’m working with a really old version, so I should check if there are any updates”. You seem to be avoiding all responsibility for your lack of good practices, and you’re still trying to spin it such that your a victim and someone else wronged you. It’s not that you aren’t clear, it’s that you start from a fundamentally flawed position that software from three years ago should still work today. That’s usually not the case for any software, and even non-programmers are aware that they need to upgrade tools. Don’t mistake your lack of discipline for failings in others.

    I spend most of my time thinking about how Perl looks to people who haven’t been using it for years. That’s why I write the books, publish the magazine, maintain the perlfaq, offer classes, answer newbie questions online, and the many other things I do to make it easier for new people to get started. I have to deal with new Perl users as my main job. I’m not just some random “module maintainer”, as you say.

    It’s extremely disheartening to have someone like you continually shift blame from yourself to general failings of a nebulous community, which you define loosely enough so you don’t have to acknowledge you’re talking about real people. The “community” that deals with the CPAN toolchain is a group of about 10 people, and within a day of your post you had three of them jumping to attention and helping you. That’s so not important to you as pointing out general failings in some strawman community and defend your rant.

30. @Skud, @brian — the “install” thing is just a weird fluke. brian fixed the app years ago, and I and others just now “fixed” it for older apps by creating a dummy install.pm module on CPAN. We should have done it years ago and we didn’t. Well, it’s done now. Shake hands and make up.

    Skud has a legitimate complaint that CPAN.pm is entirely too nice when ‘make’ is missing. That’s easily fixable. I’ll commit something to the repository today and it will be in the next major release of CPAN. (Nit: blogs are not generally where bugs should get reported, though as this demonstrates, if you make enough noise…)

    I agree that CPAN.pm is too verbose and makes the user do too much to configure it. But work on that is already in progress. See my blog post onauto-selection of CPAN mirrors for example. This improvement will be in the next major release of Perl.

    CPAN is a great strength of Perl. Using it should be easier, regardless of the operating system.

    I think brian’s point is valid (in content if not in tone) in that your original post makes it sound like people in the “Perl community” aren’t aware of the issues and it also doesn’t acknowledge any of the work being done. But since you’re returning to Perl you just didn’t know, and a newbie wouldn’t either, so you’ve “got us” there.

    But even if people are doing work to improve the tools, it doesn’t help when a major OS comes standard with a Perl that was released almost four years ago. If you’d like to find a way to contribute, that would be a great place to start.

31. @Brian – yes, shouting abusive denial at the person who discovers problems with your broken stuff is an excellent and convincing way to get all sorts of people really interested in wanting to be around people like you and, by association, the Perl community in general. Well done.

32. @dagolden: Mac OS X comes with a recent perl. Snow Leopard has 5.10.0 as /usr/bin/perl. The previous release of Mac OS X had the then current perl too. The unix tools group at Apple does a pretty good job of this, in my opinion.

33. @David: nobody discovered anything broken in my stuff. That’s the point. This issue was fixed years ago. It’s exactly why I’m upset about this: Skud keeps trying to make out that there is a current problem with my tool and this issue when it just isn’t so.

34. @brian: the issues I pointed out were:

    1) CPAN doesn’t fail loudly when “make” is missing
    2) CPAN’s output is noisy, obscuring what error messages are there, and not everyone needs that amount of output (I recognise now that my typing “install” exacerbated the problem in this case, but the general issue is still true.)
    3) Nothing in the download/install instructions on perl.org or perl.com (nor the CPAN output, though I’m more worried about the websites) tells OSX users important stuff they need to know
    3a) If you’re on Leopard or earlier, you should really upgrade Perl before doing anything.
    3b) You will need XCode, which you can get from http://developer.apple.com

    Points 1 and 2 are still true, and I emailed Andreas (the named maintainer as per search.cpan.org) about them on Friday and offered to contribute patches under his direction. He gave me some pointers and my plan was to look at it on Monday, though it looks like @dagolden may be ahead of me on at least one of those.

    To be honest I’m most concerned about the websites. Check out Python, Ruby, and PHP (PHP page is linked from sidebar on php.org download page), all of which do much better in this regard.

35. @brian thank you, your polite helpful replies are what make it a pleasure to be a part of the Perl community. I can only hope more people follow your fine example sir. Well done.

36. @kd New developers don’t by default use Catalyst ;) The main problem is when you write software for people that are on shared hosts, they haven’t got root access, and more often than not you can’t rely on CPAN to work right. I’ve got a few installer CGI scripts that will use CPAN, change it’s config so it DWIW, but then you run into problems where some build scripts (I think Module::Install is guilty of this to an extent) will just not allow for unattended installs. E.g. you can tell Module::Install to always accept the defaults, which is often what you want, but sometimes it’s not. Even if you tell CPAN you want to follow all pre-requisites, you still sometimes end up having to whack enter or give another form of input.

    One way or the other, what people end up with most of the time is a handrolled system that totally bypasses CPAN — I’ve been in the guts of those things more times than I care to remember.

    Just one of my pet peeves really, that there is no ‘easy’ way to do a totally unattended installation of modules off CPAN that can be used from, say, a CGI script, or any other application where people cannot access the shell and all they have is web access.

    The only idea I’ve got as far as that goes is a wacky combination of PAR, PAR::Dist, PAR::Repository and a build farm to turn all of CPAN into a PAR repository. No time though…

37. @kd: Not what I intended to say… I certainly have done big projects in Perl (in which case I recommend Perl::Critic and Perl::Tidy with Damian Conway’s .perltidyrc as an enforced checkin trigger), but they can’t be done just by relying on using the CPAN module install method. If you do that, you will have massive version dependency hell failures within a short number of weeks.

38. The pattern I follow on OS X is to always install the developer tools first thing, and then via `sudo` install the most recent Perl into its own `/opt/perl-n.m.o`. Then make an `/opt/perl` symlink to that `/opt/perl-n.m.o` dir. This way, the path to perl on the Mac is the same as on my servers.

    Then the `cpanp` shell to install everything else. I’ve been using `cpanp` rather than CPAN.pm for a while (well, ever since it looked like it was going to replace CPAN.pm).

39. A slight side-note about Unix tools and OSX, since many people have mentioned Fink and MacPorts. Fink and MacPorts are both excellent projects that aim to provide Mac users with a very full range of *nix toys. However, they both require the full Xcode suite as a prerequisite. I suppose that with modern drives, disc space doesn’t really matter, but it galls me to install 2 gigs of stuff into /Developer, simply to get gcc and make onto a Mac. (To my knowledge there is no other way to get gcc for a Mac. I would love to hear if there’s something I’m missing.)

    One alternative that I don’t see mentioned often is Rudix. It’s a great small project that provides a very full range of tools (including make) in binary form. It’s not a full solution for most developers since you can’t get a compiler (no gcc) from Rudix, but it’s a good middle ground for someone who literally just wants make or Ruby 1.9 or the GNU coreutils or find on a Mac.

40. If it comes down to XCode evasion, why even bother with third-party generated versions?

    If the binaries themselves aren’t hard-coded to live in a specific path, then why not just pull the binaries out of XCode itself (since they are open source) and then just repackage in a form that installs to a private location?

    CPAN.pm could be taught that on Mac, if it can’t find make and GCC, it should download some random tarball from somewhere and unpack it into $directory and use that as a fallback…

41. I love the sound of this idea, but I think it’s not legal (or at least that Apple is trying to prevent it).

    Section 3 of the license for the installer package of Xcode has this:

    You may not rent, lease, lend, redistribute, sublicense or transfer any Developer Software that has been modified or replaced under Section 2H above. All components of the Developer Software are provided as part of a bundle and may not be separated from the bundle and distributed as standalone applications.

    Section 2H is the paragraph in the license about the open-source components.

42. It’s make and gcc. Apple doesn’t own it, and I’m not sure how they could be able to say anything about what we do with it.

43. Assuming you can get Apple to give you the appropriate gcc source code and then compile it yourself, then okay.

    The GPL does not prevent people from putting extra conditions in their license, provided those extra conditions do not violate the GPL directly.

    So simply “unbundling” the copy of gcc provided in the Xcode bundle is pretty clearly against the license conditions for Xcode as described above, and the GPL doesn’t magically grant you an exception to disobey license conditions.

    In addition to that, just because the original gcc is GPL does not necessarily mean that the gcc contained in Xcode is GPL – or rather, there may be things which are used by the version of gcc in Xcode which are non-GPL.

44. Apple does provide source, and all I can say is that as a normal person (i.e., not a lawyer), it certainly sounds as though the license I quoted is saying that you can’t take their gcc and make and release them separately from the rest. (Also, given that a reasonable number of people always seem to want this, I figure that there must be a reason that nobody has done it yet.)

    Anyhow, here is a link to Apple’s online downloadable sources.

45. I am not a lawyer either, but I have a fair bit of experience in intellectual property fu and such. That license is pretty clear that you can’t take their gcc and make out of the distributed Xcode bundle and redistribute.

    The GPL is also pretty clear that Apple have to provide source for their modifications to gcc and make… which they have.

    The reasons why nobody has done it yet will be:

    1. Xcode is conveniently available and maintained professionally and provided for free by Apple.
    2. gcc + make (built from the Apple sources) is not necessarily going to be enough to actually get you a working compiled binary. It may be, but it’s a lot of work to find out, given 1.

46. @ Jeremy K

    > In particular, (1) the ‘yield’ construction on
    > iterator methods, and (2) objects in general
    > are neither one yet first-order notions in Perl

    Perl has first-class Pythonic generators/Rubyish fibers:

    http://search.cpan.org/perldoc?Coro::Generator

47. I read this post and all the comments with a lot of interest. Without responding to anything directly, there are the main points that occurred to me:

    1. Upgrading to the latest OS X too soon always jumps ahead of open-source development in various modules, languages, package installers, etc. and causes problems. I always wait for others to sort these out, and am happy on 10.5 for now.

    2. I install Developer Tools as a matter of course, but finding the right version on the Apple site is a real pain – if someone did us all a favour by creating a little page with direct links to the correct and most up-to-date versions for 10.4, .5 and .6, I’d jump for joy. I might even do it myself.

    3. I agree that CPAN is a bit verbose, but it’s usually possible to track down what caused a hiccup. I recently installed Titanium on 10.4.11 with my Perl 5.8.6, and had a grim time with deep recursion and out of memory freezes, until I upgraded Compress::Zlib. But I sent the details to Jeremy Mates and Mark Strosberg, who responded and did something about it – that’s a good community at work.

    4. I do enjoy the simplicity and ease of Ruby gems and Python’s easy_install, and generally find Ruby the most hassle-free language on OS X. But that doesn’t stop me using Perl when I choose to.

    5. I’m no *nix expert, but (thanks to OS X and Debian sysadmin work dumped on me) often find myself having to track down solutions to problems, then wanting to share them. Rather than complaining (and I’ve done plenty of that myself over problematic installs, and swearing and shouting too), a collective ‘solutions log’ might be a nice way to progress… maybe starting with Perl and OS X :-)

    6. There are some decent folks out there in the Perl community posting stuff on OS X – Jeremy Mates’ CPAN on Mac OS X was a help to me at one point; however, instructions such as the Perl Foundations’ on older versions of Perl on OS X leave me thinking ‘why so arcane?’ and ‘there has to be another way to do it’ – clear info for OS X does sometimes get overlooked in the Perl community, especially for those new to Perl on OS X.

Comments are closed.