develooper Front page | perl.perl6.language | Postings from February 2001

Auto-install (was autoloaded...)

Thread Next
From:
Filipe Brandenburger
Date:
February 8, 2001 00:53
Subject:
Auto-install (was autoloaded...)
Message ID:
F581XvpFVjCRGryWtII00009703@hotmail.com

Branden wrote:
>When I download a module from Internet, say module Foo, then I install
>it and try to use it, it promptly breaks when it tries to `use Bar'
>and sees that Bar is not installed on my system. So I have to go on
>to Internet again, find Bar, install it, so on, until I find Bar needs
>Baz, or anything
>like it.
>
>Well, I think this could be handled by Perl itself.
>This way, Perl could automatically fetch and install modules
>(supposing module install is not so hard as now, involving makefiles,
>and such...).



Well, I thought about it pretty much, and I finally realised what bothered 
me, and a (pretty reasonable) way to attenuate it a bit.

What bothers me is: Suppose I write a perl script to handle, say, currency 
conversion, or something like getting stock quotes from a variety of sites 
and building a spreadsheet table with them. That's typically something that 
would be pretty much used for `users', specially the ones that are *not* 
JAPH. Now suppose my script uses modules X, Y, and Z. X is in the standard 
library, but Y and Z are not. And Z uses module K, which isn't in the 
standard library either. Now suppose I want to make my script available at a 
web site for anyone who wants to download it and use it.

Now suppose a user (one that uses Windoze, didn't read the Camel, and barely 
can get to install Perl in binary form -- InstallShield is too complicated!) 
goes to the site, finds the script useful, and downloads it. The first time 
he'll want to try it, it will croak with a `module Y not found!'. Now, even 
if I put instructions on the web site about how to get required modules Y, 
Z, and K (which I really don't want to do for every little script I want to 
deploy), and even if the guy doesn't give up yet (which I'm sure he'll do), 
I'm certain he'll *NEVER* get the thing right, even if the modules are 
available in binary form, which I believe is not the case for most scripts.

The solution I propose to this problem is borrowed (copied) from what Java 
did in version 1.1 with jars (did wrong, of course), and somewhat like 
RedHat's rpms. What I suggest is having a kind of archive that would be like 
a container for all the code needed to run the thing, so that it can be 
downloaded and installed all at once. Not .tgz, but a thing that perl could 
recognize at his own's. A tool (`perlinstall', or something like that) 
distributed with perl would take this package and extract scripts, modules, 
..., and install it in the right places, with minimal (ideal zero) user 
choices.

Well, the thing with rpms is that they can be source, binaries, or platform 
independent, what is represented by having .src, .i386/.ppc/.alpha/..., or 
.noarch on the name. The same could be done with perl. The src would include 
the source for all needed modules, besides the scripts that the user is 
supposed to use. If any of the modules use XS (or its sucessor), it would be 
possible to build binary packages, that would take the burden out of the 
user to deal with C compilers and make (which is one thing I hope to see 
stripped off of module building, in Perl 6 -- since we have a MakeMaker, we 
could have a Maker that does it all! Advantages? Platform independence and 
no need for external tools but the C compiler).

Dependencies generators would be necessary as well, but I think there are 
some already.

Comments?

- Branden

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About