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.
