Stories
Slash Boxes
Comments
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.

Why Ruby is prettier and Padre changes the Perl community 2 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Use cases...
    • End user can download and execute an application implemented in perl application without knowing what Perl is.
    • Developer can easily add, remove, and upgrade Perl modules without affecting system/os Perl installation. (Default to having CPAN install to a user_perl overlay?)
    • Systems Administrator can easily add, remove, and upgrade site_perl without affecting developer and/or application overlays.
    • Developer when releasing perl application has easy way to bundle all current differences from the installed vanilla/core Perl distribution into application distribution. I.e. option to use pre-existing perl w/ application overlay or standalone perl app install.
    • A best practices / EPO / Modern / Strawberry / etc. CPAN bundle of modules which work on *NIX, Windows, OSX _AND_ which can be installed and upgraded without requiring external development tools. I don't care if this requires a pure perl implementation for all dependencies... or a way to ship binaries. -So long as we don't require the installer/developer to have or use a C/C++ compiler, etc.

    A common thread in these use cases is that different module versions should be able to co-exist in an installed perl distribution. The most common cases are probably system perl, developer perl, and bundling an application's dependencies.

    How to add this complexity without making it a burden? Allowing us to keep around all versions of modules? Have different levels of overlays beyond site_perl?

    However implemented... It would be nice if the solution didn't require completely separate Perl installs or a revision control system.

    • #5: in Strawberry's case, we provide the C/C++ compiler - so it's really not external, but it is provided for those things that need it. For most non-Windows operating systems, I do have to admit, Perl assumes that a C/C++ compiler is accessible for a lot of things. :)

      And "Strawberry Professional" will have a lot more things prebuilt.

      We "do" have a way to ship binaries, at least for one module at a time - it's called a .par file. How good it is for your purposes, I don't know. PAR::Dist is the handler for t

      --
      The new Strawberry Perl for Windows has been released! Check http://strawberryperl.com for it.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.