NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Not with the tools we have... (Score:1)
Let me explain: The default installation paths for the traditional Perl resources are taken from the compile-time %Config hash. This includes various paths for modules and their binary parts, but no concept of user directories,
Naturally, %Config being populated on perl-compile time cannot and should not provide this information. But scanning the system File::HomeDir-esque during installation and making guesses on b
Re:Not with the tools we have... (Score:1)
File::ShareDir is built entirely on it. It installs files into the
While I agree that teaching the CPAN infrastructure about the other resource types is likely to be impossible, I'm not entirely sure that asking the user is necesarily a bad idea.
We already let users override the installation paths via things like PREFIX. So in principle the concept of user-driven configuration is not necesarily a bad idea, particularly on small installations.
And since CGI isn't highly scalable that fits in nicely.
Since I wrote this entry I've been reminded of kwiki and the catalyst code-generation programs.
You install the main modules for the application into the system installation, and you put all the rest of the files into
You then install a secondary installer that you run as a user. This can ask per-instance questions and scan the local system, then generate an installation that is self-contained within a single user's cgi-bin dir, assuming they have one.
On the plus side, they could also then override things like template files, and tweak the configuration later.
It would at least require that the system administrator had installed the main application.
Reply to This
Parent