tachyon has asked for the wisdom of the Perl Monks concerning the following question:

One of the good things about Windows based software is the ease of install. Click to install and it is done.

As I see it one of the things really holding back Open Source is the fact that it is not always easy to install widgets and get them to go vroom. OK so we are programmers so generally it does not seem like ./configure --PREFIX=/hide/it/here;make;make test;make install; etc is all that hard. But what if you are not a programmer? What if there is more to it than this example. What about uninstalling cleanly?

Non programmers, or know a little bit people want one thing - software that does stuff. In order to do that stuff you have to install it. To install the average perl script you will probably have to be familiar with tar +/- gzip *before you can even get to* the README README_FIRST INSTALL INSTALL.configure .....

I have just been packaging up a Webmail script that runs off the back of a pop3 server. It basically provides the full functionality of Outlook within an HTML browser interface - Outlook web access for *nix - not exchange server or M$ in sight. To do this it needs access to the filesystem for folders and database access for the address book, task list and calendar. It uses CGI, DBI, DBD::mysql/PgPP/Oracle, Net::SMTP, Crypt::CBC, Crypt::Blowfish; MIME::Lite; MIME::Base64, Mail::POP3Client and Text::Wrap. Most of these modules are not in the standard distro so may need to be installed. It needs a database setup. It has a range of config questions about SMTP and POP servers and other options that need to be answered.....etc

The config script to set this up runs to about 1000 lines but having run this and answered the requisite 20 questions everything required should be set up and it SHOULD just run....

The thing that struck me is the commonality of the sorts of task that the config script is doing (similar to the last one I wrote, etc):

  1. checking for modules that are not installed and offering to install them with CPAN, ppm or apt-get depending on platform
  2. checking the OS, filesystem delim, CWD etc
  3. prompt for an answer to a question (offering a default)
  4. do stuff depending on the answer
  5. modifying config file(s)
  6. copying files from a to b
  7. setting permissions
  8. creating a database and setting user and password
  9. initializing database tables
  10. cleaning up

It seems to me as though these tasks are common ones for many application installs. Is there an existing framework to do this. The goal would be to have and INSTALL file that reads

Short version for the impatient. Actually there is no long version. To install this widget type ./config.pl at the command line, and answer the questions... When you are finished reboot your machine (sorry just kidding ;-). When you are finished answer yes if you want to start your widget righ +t now. If you don't want to start it right now read the file MAKE_WIDGET_GO_N +OW If there are any problem use the ./support.pl widget to email the content of the install.log file automatically to the auth +or. Solutions to common *issues* can be found in the SUPPORT file if you want to help yourself.

Is there anthing out there that is providing this kind of framework? If there is not what other tasks would you like to see in an idiot resistant installer and I might just write one.....

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Edit by tye: READMORE

Replies are listed 'Best First'.
Re: Is there a perl version of MSI
by dingus (Friar) on Dec 20, 2002 at 11:49 UTC
    Gosh talk of synchronicity! I was just about to mumble something on the same lines. I've started looking at NSIS as a free windows installer and was wondering what I should do for the Cross-platform installer.

    Anyway here are some thoughts at semi-random.

    Your 10 tasks looks pretty much correct

    It may depend on what your appication is but often the 20 questions can be asked nicely on one or 2 webpages so - if your app is a WEB app then how about a trivial

    ./install.pl /path/to/cgi-bin/ browserapp <url>
    
    one liner that copies itself to the cgi-bin directory and then runs the browser pointng to http://localhost/cgi-bin/install.pl which does the rest.

    Make sure you have an uninstaller (i.e.

    ./install.pl --uninstall
    
    must "just work") and uninstaller must have the option to keep files that were installed in shared locations such as /usr/lib/perl...

    If you could support the NSIS script format then it would be really easy to make a combo *nix/windows installer

    For apps that don't need any web interaction a standard set of questions (where to install...) and sensible scriptable defaults would be good.

    One big irritation with windows installers IMO is that they often seem to expect to be run as "Administrator" even though they probably aren't really doing anything that needs such access. Need to make sure that the *nix equivalent doesn't abuse root.

    Installer needs to be able to bootstrap itself from a minimal setup. ?Can you assume perl is installed?

    Dingus


    Enter any 47-digit prime number to continue.

      With an installer you have to assume somthing. Assuming that they have an OS is safe and if they have an OS it *can* run perl one way or another so coding in Perl makes sense to me (beside the obvious fact that if they don't have Perl well what can you say...) For most flavours of *nix perl is a given, for MS you could wrap the package into an exe with perl app. If you are looking at a Perl installer (as I am) Perl should be a given but as you say....

      As you point out root/Administrator access is not always required although it almost always makes life easier. On Win2k Administrator is like root with the good bits removed anyway....

      If you want a GUI HTML/CGI is the way to go but then you run into the issues of needing a browser and the ability to write a CGI with root issues and the assumption that you have httpd/IIS. Console is more portable, GUI is nicer

      For an unistaller you need basically just need to write a file that lists all the changes so you can try to roll them back. XML along the lines of:

      <write> /some/file/here/file.txt </write> <modify> /some/config/file.conf <change> <add> this </add> <delete> that <save> that here </save> </delete> <modify> s/this/that/ </modify> </change> </modify>

      No choking if something is not where it was or the permissions are wrong, etc.

      No delete, just modify and add so you can un-modify and rm to rollback.

      cheers

      tachyon

      s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Re: Is there a perl version of MSI
by Mr. Muskrat (Canon) on Dec 20, 2002 at 15:14 UTC

    tachyon asked Is there a perl version of MSI?

    Yes, but you may not want to pay the price... It is a part of the Perl Dev Kit by ActiveState.

    What is PerlMSI?
    The PerlMSI utility is used to create Microsoft Installer database files with .msi extensions.
    -- Perl Dev Kit User Guide

Re: Is there a perl version of MSI
by diotalevi (Canon) on Dec 20, 2002 at 14:51 UTC

    Autarch mentioned he was doing some work on this at a recent perl mongers gathering. I seem to recall his installers used a combination of Module::Builder and maybe Mason as well. Or maybe he was just writing his config system in that. I forget. I'd send him a note (follow the links from his home node and get an e-mail address that way).


    Fun Fun Fun in the Fluffy Chair

      I have done work on installers. Most of what I've done so far involved awful hacks with ExtUtils::MakeMaker. Doing it with Module::Build (not Builder) is a hell of a lot easier, and I've done a bit of that as well. None of this had much to do with Mason directly, BTW.