On Dec 12, 2003, at 7:25 AM, Jeff Westman wrote: [..]
p0: most of the cool arguments have been generally made. my kvetching here will therefore be the less cool stuff.
So, installing a module is out-of-the-question. In my case, I am basically "stuck" with the perl [5.8] default libraries and modules.
Yes, and No. Again the presumption here is that we are discussing at the 'professional obligations level' and not at the academic/hobby level.
I had a contract where the obligation was, well so
tight that I could not even presume that CGI.pm would be installed.
So I wound up documenting the core basic perl modules that had
to be there, I think Socket.pm and one other - as Required to
be there. { note - we will return to this TPFH whine later
in the section on application library, below. This is
forward referencing for the compiler...}So the 'no' side of that rests upon arguing the case that the Foo::Bar module HAD to be a part of the 'install' for the project. Something that I did back when Sys::Syslog was NOT a part of the default 'core bundle' - since it was just easier to get it into the required modules lists that would be installed on the production systems than have to re-write all of that code.
[..]
While the solutions shown here will most often work,
they aren't practical for Joe Programmer working in the corporate world
(don't flame me! LOL) who doesn't have access to install as root or install
on many many servers.
As noted above, unfortunately there is no module
Fix::Broken::Management::Food::Chain
but I think we would all love to install it if anyone could get the time to debug it...
{ small technical design problem to note - if folks
thought that keeping track of cross platform OS issues,
including whether to retain support for VMS was ugly,
has anyone even begun to work on the topology of
MangledManagement... I mean, think about the problems
of implementing a simple
$fbmfc->bad_manager_no_banana_for_primate()
method that would allow a simple interface generic
enough to cover all of the primates???}So one side of the 'joe programmer' problem is how to get MangleMent to 'get it' about
a. open source solutions
b. getting modules into the build train
so that they will just install as a part of
the overall process....In one organization the PerlKabal had stronger Voodoo than the PythonKabal in that the PerlKabal just stepped up to the plate and solved the problem of how to 'pre-build' the CPAN modules and get those 'pre-builds' into simple Solaris Pkg installables so that the Solaris Package Management software would do the whining for us about required package version control. So from the standpoint of Manglement, they didn't "know" that the FOOpl was the base perl release and that the FOOplx were the CPAN module Extensions - even IF the freaking
pkginfo -l FOOplx
said that it was our set of CPAN module extensions... They just went "is solaris package, is required, is on check list, must be installed, installation good...."
So a part of the issue is how to solve the correct brokenness.
[..]
[..]I suppose one way to point to a CPAN module and not have to install as root would be to install the module in the application library path.
Now you are starting to have that Decaff Moment.
There are two 'issues' with this 'application library path' phrase, since it can either mean:
a. relative to the 'bin dir' of the project
b. in my home directory where I stash stuff...In the former case, I am SOOOO there with you. If you look at the stock Mac OSX model the foo.app is actually a 'directory' where inside there is an executable and all of the associable stuff that goes with it. There are many ways of solving the offset from where the code actually IS when executed,
cf: perldoc FindBin
and you are so ready to be rocking that solution.
Catch_forward_reference_here:
As noted in the first part, the problem of 'not being allowed to have CPAN modules' as a part of the project was driven in part by the problem of needing a 'pure perl solution' that of course precluded any module that required XS components, as well as would lead to those unpleasantries were someone to 'fix' the site_perl section on a host. Fortunately the GreatLeader was not so JackBooted as to say 'no modules'.
Merely that the modules were NOT going to 'install in the same old CPAN way' into site_perl - so the work around was to manually tree them down in
$INSTALL_DIR/lib/<corporation_id>/...
hence all of the cgi code had the caveat
use lib "../lib";
and of course the obligatory form
use <corporation_id>::Foo::Bar::Baz;
So the same strategy can be re-used for non-cgi code, one just has to give up on certain luxuries about doing it the 'traditional perlish way'...
{ yes, it is possible to be APOSTATE about perling...
but be very, very careful about it, and don't tell folks. }Most of us start laying out our home directories in the form
$HOME/lib
perl5/<modules_here>
$HOME/bin
$HOME/etc
....So in my case for things I am working on whether or not it is really worth having this module on the big list of 'just gotta have' I'll download the module from the CPAN, unwrap it, and run say:
[jeeves: 8:] sed 's/^/### /' PerlInstall
### #!/usr/bin/perl -w
### use strict;
### #
### #/home/drieux/bin/PerlInstall - you know to install stuff locally
### #
###
### my $prefix = $ENV{HOME};
### my $lib = "$prefix/lib/perl5";
### my $man = "$prefix/man";
### my $cmdArgs = "PREFIX=$prefix LIB=$lib ";
### $cmdArgs .= " INSTALLMAN3DIR=$man/man3 INSTALLMAN1DIR=$man/man1";
###
### my $cmd = "perl Makefile.PL $cmdArgs";
###
### system("make clean");
###
### system($cmd);
### system("make test");
### system("make install");
###
[jeeves: 9:]without having to be root. Then I can play around with the code by simply doing
use lib "$ENV{HOME}/lib/perl5/";
in the script itself. See what comes of the play, and move on down the line to the next issue.
Which also helps beat the Kinks out of one's 'installer'
since if the above will not work on one's fresh brand new
perl module, then there is more work to fix something.
{ What Whiney Little Widget did I scrag in that Freaking
Makefile.PL EX::MM wackaFreakingDoodeleageWakeFestThisTime... }so it all sorta depends upon what the writer is trying to 'solve' in the issue that the other person raised. Not to mention how much time, and effort, the writer has to go into depth on the issue(s) raised.
ciao drieux
---
Oh yes, it is also important that you make clear in the comment bars of your new perl modules, which parts were ripped off from ideas that were stolen from which vector of infection. This way Pure Perl Purists will know whether you are on the True Path of True Perl or a part of the Sinister Dark Hand of Perl espoused by the Apostate and Evil Ones...
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
