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.

module install 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Can you get a dedicated perl user that owns /usr/local/perl and install your own instance there [perl.org], where you can manage the modules yourself? Can you install your own instance as your own development user somewhere in /home or something?

    Not having access to Text::CSV_XS is ridiculous. Having to wait two weeks for it is ridiculous. Not being able to put it in a development area yourself to work with would be beyond ridiculous, but hopefully you can at least install the module somewhere you have write acce

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers

    • Developers ought to have complete control over the development platform. This is the reason. If administrators are required to "protect" something, then that something should be production, and your organization would be well-served by formalizing the boundaries between development and production, and letting the developers have control over the development server/instance.

      I both agree and disagree with you here. Most developers do not know how to properly administer a server or even their own workstatio

      • I'll also both agree and disagree with you. :) Developers should have the support of admins who do maintain the OS, etc. There should be some standard configuration the admins can restore, and the developers ought to be able to request needed changes (for some apps that might be the OS level, for others it might be as simple as a Perl module or even a config file) and receive those in a timely manner, and all of it ought to be well-controlled and not put into production until it is well-documented and rep

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • on the development server, i can install modules to my home directory and use it from there. however, i need to make sure that the module that i am using under dev environment will be available to me on production.

      in the linked journal, you are using CPAN for moudle installation. do you do that in production environment? if not, do you build pkg for each module for every version of Perl? do you reuse some of the Perl modules built against older Perl?

      also, you mention the update of symbolic links from /u

      • in the linked journal, you are using CPAN for moudle installation. do you do that in production environment? if not, do you build pkg for each module for every version of Perl? do you reuse some of the Perl modules built against older Perl?

        Sadly, when it comes to Perl, the lines between development and production are badly blurred in my organization. Happily, it tends to affect only me. :)

        I have gone the route of building Solaris packages for Perl modules. I would never do this again, if I could help it. I believe the ideal situation would be a production installation of Perl managed by CPAN shell and never touched to add or upgrade a module until all code had run regression tests against a development instance that had been so updated

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.