Re: [OT] RE: modperl growth
On Tue, 5 Feb 2002, Dave Rolsky wrote: On Mon, 4 Feb 2002, Andrew Ho wrote: One last thing that is hard is where is your DocumentRoot? This is a huge problem for web applications being installable out of the box. Perl can't necessarily figure that out by itself, either. You take a guess and then ask the user to confirm. And you can't guess you just ask. That's a good strategy (assuming a missing if in there somewhere). It can be augmented with the tactic of check for a running apache, see where it gets its config file from, and parse the config file to get the initial guess. (Note that I wouldn't want this to be a final guess; I'm using mod_perl in a virtual host config; the main apache config doesn't use it, and has a completely unrelated docroot (/usr/local/apache/htdocs as opposed to /home/appname/public_html)) There's nothing wrong with an interactive installer. What kills mod_perl apps is they simply have a README or INSTALL that says Copy all the template files to a directory called 'app-root' under your document root. My what? Which files are templates? I don't know this unix stuff; copy doesn't work right. I think we've all probably heard these words before... I guess my point is that installation is hard. Rather than trying to make it work for everybody out of the box, you should make it work for the typical case out of the box, and then provide hooks for installing it in custom places. I think the best installer is an interactive installer that tries really hard to provide good defaults. I agree; while I frequently leave unimportant considerations alone (note my main docroot above), I tend to have very poor luck with the works with the typical case out of the box, and then provides hooks which change with every bloo^W^W^W^W^Wfor installing it in custom places. I won't go into speculations why. Ed
[OT] RE: modperl growth
:: - Install Apache and mod_perl, or use an existing installation. :: :: - Install all the needed modules, template files, images, etc. [cut] Dave, I too try to automate installations as much as possible. Within Perl, I've found it possible to dispense with a separate configuration file for almost any application, even those with an RDBMS back-end. Under *nix it's really easy to automate things, under Win32 it's a little more difficult (file permissions are a bastard to manipulate). Perl can analyse its own environment very accurately, and once it has this awareness it's really easy to achieve automation. Anyone can do this, but most of us are too lazy for such niceties, which is too our detriment I think. However, all of my work in this direction requires that Perl and any required modules/libraries are already installed - I have never attempted to do an all-in-one install, although I do see this as being relatively easy to achieve. I would love to contribute to any efforts towards an out-of-the-box installer. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/
Re: [OT] RE: modperl growth
Hello, JHI've found it possible to dispense with a separate configuration file JHfor almost any application, even those with an RDBMS back-end. Under JH*nix it's really easy to automate things, under Win32 it's a little more JHdifficult (file permissions are a bastard to manipulate). Perl can JHanalyse its own environment very accurately, and once it has this JHawareness it's really easy to achieve automation. So you are right about this, but let me add a caveat. Many times you need to cooperate with a third-party package management system. For example, an RPM database, or a stow or encap repository. In the latter case especially the paths that files are referenced at (typically /usr/local) differ from the places they actually live (typically a mounted repository). (I believe the Andrew File System has a similar problem, too.) Stuff using GNU autoconf is pretty easy to work into this by specifying a PREFIX at configure time. As of Perl 5.6.0 the Perl base install system accomodates for this as well, allowing you to specify different stuff to go into @INC versus where make install puts the package. Perl modules aren't as nice to fix. They automatically want to go where Perl is installed. If you want to rev packages separately, regular make install doesn't do the right thing. One last thing that is hard is where is your DocumentRoot? This is a huge problem for web applications being installable out of the box. Perl can't necessarily figure that out by itself, either. I guess my point is that installation is hard. Rather than trying to make it work for everybody out of the box, you should make it work for the typical case out of the box, and then provide hooks for installing it in custom places. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: [OT] RE: modperl growth
On Mon, 4 Feb 2002, Andrew Ho wrote: One last thing that is hard is where is your DocumentRoot? This is a huge problem for web applications being installable out of the box. Perl can't necessarily figure that out by itself, either. You take a guess and then ask the user to confirm. And you can't guess you just ask. There's nothing wrong with an interactive installer. What kills mod_perl apps is they simply have a README or INSTALL that says Copy all the template files to a directory called 'app-root' under your document root. I guess my point is that installation is hard. Rather than trying to make it work for everybody out of the box, you should make it work for the typical case out of the box, and then provide hooks for installing it in custom places. I think the best installer is an interactive installer that tries really hard to provide good defaults. -dave /*== www.urth.org we await the New Sun ==*/
