Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Theory (10)

Theory
  (email not shown publicly)
http://www.justatheory.com/
AOL IM: dwTheory (Add Buddy, Send Message)
Yahoo! ID: dew7e (Add User, Send Message)
Jabber: Theory@jabber.org

Perl, PostgreSQL hacker; US politics junkie; Webapp developer; Portvangelist; profane iconoclast.

On CPAN see: DWHEELER [cpan.org].

Journal of Theory (10)

Tuesday June 04, 2002
06:49 PM

All about App::Info

[ #5423 ]

Yesterday I released App::Info to the CPAN. I started it on Friday, and put the finishing touches on it just yesterday. It was a busy weekend.

I got the idea for App::Info after looking at the work Sam Tregar has done building an installer for Bricolage. He had done all this work to determine whether and how Apache, PostgreSQL, Expat, and libiconv had been installed, and it seemed a shame not to take that code and generalize it for use by others. So I whipped up App::Info, with the idea of building a framework for aggregating data about applications of all kinds, specifically for the purpose of determining dependencies before installing software.

I think it has turned out rather well so far. I added code to determine the version numbers of libiconv and Expat, although it's imperfect (and that accounts for the CPAN-Testers failures -- I'll have a better release with some of the bugs fixed shortly). But overall the idea is for this to be a uniform architecture for learning about software installed on a system, and I'd like to invite folks to contribute new App::Info subclasses that provide metadata for the applications for which they're most familiar.

That said, this is a new module, and still in flux. I've been talking to Dave Rolsky about it, as he has been thinking about the need for something like this, himself. In the past, Dave and I have talked about creating a generalized API for installing software, and Dave has even set up a Savannah project for that purpose. In truth, I had envisioned App::Info as one part of such an initiative -- the part responsible for determining what's already installed. And while the API I've created is good for this, Dave points out that it's not enough. We need something that can also prompt the user for information -- to determine if the right copy of an application was found, for example.

I think I can work this in to App::Info relatively easily, however. Currently, if App::Info can't find the data it needs, it issues warnings. But this isn't the best approach, I think. Sometimes, you might want such errors to trigger exceptions. Other times, you might want them totally silent. So I was planning to add a flag to the API such that you can specify the behavior for such errors. Something like DBI's RaiseError or PrintError options. But then, it's just another step to add a prompting option. Such an option can be changed to prompt for new data at every step of the process, or only at important points (like finding the proper copy of httpd on the file system) or only when data can't be found.

So I hope to find the tuits to add this functionality in the next week. In the meantime, I'm going to try to keep up-to-date on my journal more.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Currently, if App::Info can't find the data it needs, it issues warnings. But this isn't the best approach, I think. Sometimes, you might want such errors to trigger exceptions. Other times, you might want them totally silent. So I was planning to add a flag to the API such that you can specify the behavior for such errors. Something like DBI's RaiseError or PrintError options. But then, it's just another step to add a prompting option. Such an option can be changed to prompt for new data at every step of t
    • Actually, that's more or less exactly what I was thinking of doing. The various subclasses would know what to do with a throw() depending on how the verbosity flag (for lack of a better word) was set.

  • The iconv checks look like they won't work very well across multiple platforms. A lot of platforms support iconv (the library) but don't have iconv the binary installed.

    It's this reason why AxKit's installer actually tries to compile a small XS module in order to test for the presence of iconv. You also need to know whether iconv is in -liconv, -llibiconv, or -lc.

    Yes, it's all horribly complicated, and pretty much the only way to be sure is to compile something and see if it runs.
    • I'm not surprised. It's just something I threw together as an example. Some versions of iconv.h don't appear to have the version number in them, either. However, I didn't get into this to have horribly complicated things to do (only PostgreSQL is easy to interrogate). Rather, I wanted to create a uniform interface for this sort of thing, and people who know more about the various packages than I do could contribute them and keep them up-to-date.

      IOW, patches welcome!