Several mostly-unrelated comments:
- Perl6 will address the XS issue by assuming you have Parrot installed. Since Parrot does all the heavy-lifting, nearly every CP6AN distro should be "pure-perl".
- The primary issue isn't "How do I install this as a non-root user?" but "How do I install this in a place that my code will find?" You are generally expected to be root because the perl executable has root-only paths hard-coded. It seems to me that we need to do two things:
- Provide more documentation/tutorials/whatever to get "use lib" into more use.
- Provide an easier way in CPAN(PLUS) to install into a directory on a per-install basis. Maybe something like "install Foo into lib" or "installdir lib\ninstall Foo" or something like that. But, configuring CPAN as a non-root user when there's already a root user requires source-diving and crazy configuration. If you're not a root user, it shouldn't use the root config.
- Building on the prior comment and using Dadamail as an example, Dadamail should be able to specify to CPAN(PLUS) that it wishes to install all the prerequisites into a given directory, assuming that the prereqs aren't already there. You should also be able to specify to Dadamail where your personal installs are, if you wish. Then, Dadamail should be able to build a string of "use lib" items that it places in a special .pm file that it sources in immediately, probably through 'do' because 'use' scopes too much. That kind of work needs to be automated.
- The XS issue in Perl5 is a tough one, especially as most interesting apps will want to use MySQL and DBD::mysql is problematic in a shared-hosting environment. You either compile against 4.1+ or pre-4.1 and the two cannot live together, just like MP1 and MP2 cannot live together. Maybe C-compilers are just a requirement with free ones listed (gcc, MingWcc, etc).
- The interface to CPAN needs improving. The three .gz files that get downloaded shouldn't be that way by default. Whenever I go to cpan, I'm usually issuing 1-3 "install Foo" commands and that's it. cpan should be able to ask some CGI front-end "What's the correct FTP command for grabbing the Foo module?" and let a centralized database do the rest. Here's why - I often want to build my own personal CPAN so that I can use CPAN.pm to update my company's modules on production instead of using SVN. That's just one more thing to install on production machines and I don't like that. (The alternative is bundling and installing by hand which is fraught with danger as befits any by-hand solution.) If the API for CPAN was a clear and simple solution (with maybe a personal CPAN app?), then doing this would be a piece of cake. Imagine that as your upgrade solution for your company's modules!
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
