Re: [MacPerl] Installing on Users' Macs

[Matthew Langford <langfml [at] eng [dot] auburn [dot] edu>]

If MacPerl is already present, what then?  (Is there an easy way to
determine this, and can it also determine the presence/version of
modules?)  Do you just install your script, and hope that the core and all
the modules present are up-to-date, but not overly so?  (Overly so, in the
sense that years from now, when the user finally stumbles on your killer
app but has Perl 6 installed.)

Or do you install your own MacPerl folder, with its own creator code(??),
and ignore what is already present?

Do you unlock and replace the core and any appropriate modules if they are
older than the ones you use?  This seems most practical to me; but it may
be the most work.

For MacPerl to become wildly popular, though, we need a scalable approach. 

What do I mean by scalability under popularity?  Consider what happens
when someone installs multiple MacPerl-based programs from multiple
authors.  This particular someone is a non-programming, non-computer-savvy
Mac user (the Rest of Us).  Well, if MacPerl scripts typically install an
11.1 MB "gift" (that's the size of my MacPerl folder), MacPerl will get
the reputation of extreme bloat.  On the other hand, if the user often has
to worry about the dates on files in a MacPerl folder, we need not worry
about MacPerl popularity. :)  So asking the user about things they don't
understand and blindly installing a full-but-private MacPerl are not
scalable.  Multiple authors would have to coordinate how to minimize
duplication of core and common modules, while also minimizing conflicts
around the commons.  This coordination is what we can hopefully accomplish
now.

I see two useful pieces of code (neither of which I have the time or
know-how to develop--I apologize):  a snippet (module?) of Perl which
looks for a preference file in the system folder; this would reveal the
presence or absence of MacPerl, its version, and its installation path.

If it isn't installed, then install it.  (_Where_ is open to question.)

If it is installed, then switch to that interpreter.  When running under
that MacPerl, one can test for modules and versions, and install (ONLY) if
you have/need a later version.

You may be smiling and thinking, "what good is a perl snippet deciding
how/where to install, when perl isn't installed yet?"  Ah, that's the
second useful program.  A MacPerl-based Mac installer (which must include
its own interpreter).  This has the advantages of using Perl to decide how
to install Perl, and making the future installation of modules (MacCPAN)
one step easier.  Is there more to an installer than copying files?
Perhaps it also includes g(un)zipping and (un)tarring, which are also
available under MacPerl.  I think.  [Gzip and tar over Stuffit because
they are free, public, and cross platform.]  

Again, with a Perl installer (Mac installer modules plus Perl
interpreter), one could distribute a Mac CPAN module which after a
download and double-click just does the right thing.  With a bit more
cleverness, someone might build in line conversions and file location
translations and try to autosupport many of the traditional CPAN modules. 
That way, we could sit around and grumble about how youngsters these days
have things too easy for them, and how we used to envy Unix CPAN, and how
we used to install files by hand in obscure locations. (And _enjoyed_ it!)

But as I often do, my dreams/designs are outstripping practical
implementation considerations. 


--
MattLangford 



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch