Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 1. Stop assuming that Unix isn't only the default platform, but the only platform.

    I really think there are very few places where this is done on purpose. Generally people write cross platform code - in fact perl makes it pretty hard these days to make non-cross platform code. The only case I can think of is Windows' screwed up filesystem conventions, where there is no root to your filesystem. Finding people using File::Spec in their modules tends to be a rareity. But even then I don't think File::Spec can guess which drive you meant stuff to end up on.

    2. Modify h2xs to produce non-Unix friendly output:
                        * Supplement the make/test/build lines in the default doc with info on how to extract to a local subdirectory w/o root privileges.
                            (It's a pain to look it up every time, and makes us non-super users feel like outsiders).

    I think this has a place in the README, but not in the output from the tools. I have an incling this is already done now though.

    * Have the documentation automatically indicate whether the module, and its dependencies, are pure Perl or not.
                The default is spreading FUD about the need for a compiler. What percentage of CPAN modules really require one?

    This is a tough one. While yes a lot of CPAN modules (probably the majority) don't require a C compiler, that doesn't necessarily map directly to the most popular modules. Looking at the top downloads from kobesearch I would say the of the most popular modules more than 60% require a compiler. I really really think this is a windows problem. Almost every other OS on the planet ships with a free compiler, in fact even windows is starting to ship with one (shame it's only for C#.NET), but they stubornly won't ship a C compiler. Frankly I think it's reason enough to dump the platform, but YMMV.

    3. Replace make as the default with one of the new Perl modules being built for that purpose.

    That's already being done - see the Module::Build project.

    4. Have said module be smart enough to detect
                        * Lack of root privileges

    That's a tough problem. It's not *just* root - some users install under other users that have write access to the site install directory. And there are often a multitude of reasons why an install might fail, so you can't just check for lack of write access. Plus you can't do these checks at "perl Makefile.PL" time, because most sensible people run that as non-root. There may be some mileage in asking the user at "make install" time if the copy fails to check they are root, but there's no real way to do this cleanly that I can imagine.

    * Lack of compiler

    Sounds like a sane thing to do.

    and be smart enough to gently guide users to making the correct choices:
                        * install locally and put in a use lib command
                        * download a gcc compiler and compile

    Sometimes neither would be the right choice.

    * connect to ActiveState and download

    Frankly, that should *always* be the first port of call for Windows users.

    5. Form a better connection with the ActiveState repository, so Pause automatically sends c-based modules to the PPM repository.

    This is an ActiveState problem, not a CPAN problem really. ActiveState have to QA everything, and that's time consuming. Putting a module in PPM for them is a big deal - it means they basically support the use of that module.

    I don't mean to sound too much like a naysayer here, but a lot of these problems can be solved in places other than CPAN, or are being worked on already, and I thought you should know that.