in reply to Re: Testing for non-perl system requirements
in thread Testing for non-perl system requirements

Alien is a horrible namespace choice. Yes I know it's been approved by Brian DFoy (cpan dungeon master) and his minions.

I think Damian Conway (perl feng shui master) would not approve. Namespaces should be descriptive. Could have been 'Notperl'.. who knows.. Alien?! Eek!

I think the 'Alien' concept stinks like system maintenance. I think this kind of thing is likely to work only on posix systems, and then.. there are better ways to install things if they are missing. I would be sketched out about having perl hacks to detect if you have things like rpm and yum. Yes, not that Alien decrees that.

By what I see of the Alien concept, you would have a Alien::MySQL which would detect if you have mysqld, mysql-devel mysql-client.. who knows--- before you install DBD::mysql.

It seems to me that detection is plenty help already. After that, it seems the likely people to be installing non-perl libraries would be admins. Yes, I know.. users can too.. Pfffttt.. users...

Users installing non-perl resources should probably not be given a perl hack to help them out with it ?

  • Comment on Re^2: Testing for non-perl system requirements

Replies are listed 'Best First'.
Re^3: Testing for non-perl system requirements
by Anonymous Monk on Apr 03, 2008 at 04:17 UTC
    Like they say, if you think you can do better ...
[reply]

      Sometimes doing it better is using the tools provided.

      In this case, the Alien idea is not stupid, without merit, etc. Some of the concepts simply wreak of things that would better reside in rpm/src/makefile land, downloadable packages.

      I believe in checking for missing non-perl dependencies/ operating system/ weather conditions, before installing perl modules.
      I believe in scripting hacks to install non-perl dependencies.
      Creating a standardized perl solution to installing things that are very particular about other dependencies and portability in general.. Could be a tremendous waste of time.
      So, my way of doing some of these things better is to not do it.

      Take for example Alien::CodePress. It installs something for a website.
      Who would make use of this to install javascript and html ona website?

      • A user with a shared hosting account?
        What are the chances that Alien::CodePress is already available in the system? She is going to what, install the module, write a script that uses it- all to install html and js files on a website???? Good excercise- but that's all it is.
      • Someone with a dedicated server?
        Really? You think so? Instead of wget and tar?????
      • A sys admin to managed hosting accounts
        Here's a good chance for usage. Maybe they would offer users through a control panel to install CodePress to a managed hosting account.
        Chances are they have a bash/perl script of their own to do their dirty work. Maybe one they slightly modified from the version that took care of awstats or some other.

      Don't get me wrong, I love what they are doing. Go for it. I will stand behind the developers and cheer as they code and debug their little fingers to the bone.
      Just as I have.
      Even if you reach a dead end (and I've had oodles), you learn- you earn a greater respect and fascination for your peers and beyond, who are creating amazing things and sharing it with the rest of us all.

[reply]
[reply]

In Section Seekers of Perl Wisdom