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.
 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
    • 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 first, to test. Then, simultaneously, a development instance where modules are updated all the time, as long as they pass their own tests, to smoke out potential problems as soon as possible in development. (With more developers, you probably wouldn't want the dev instance to be so "bleeding edge," but more intermediate between the two extremes.) One approach to production might be to build your own local CPAN repository that contains only tested and approved versions of modules and then have the production server(s) update from that repository only. Another approach might be to distribute a single custom Perl package (doing /usr/local/perl/5.8.8 makes it easy/easier) as a tar.gz or as an OS package; you release a new update to the package when you need new modules added or a newer version. I'd rather do that than separate OS packages for each module. If there's only one OS package to deal with, then your environment is far more predictable. :)

        also, you mention the update of symbolic links from /usr/local/bin/ to /usr/local/perl??/bin/. such as perldoc, splain. my question is why aren't those links in /usr/local/perl???/bin/ ?

        I should mention that now instead of /usr/local/perl588 I recommend an installation location of /usr/local/perl/5.8.8 . This puts all (or most) installations of perl under a common directory which can be much handier (and keeps /usr/local cleaner).

        Under my recommendations, /usr/local/bin will contain symbolic links to links to the real version of each utility in /usr/local/perl/x.x.x/bin. I'm not sure I understand your question as those links cannot be in the other location because the real versions of the utilities are there. ??? Under this layout, developers tie their programs directly to something like #!/usr/local/bin/perl5.8.8 on the first line of the program; then, when new versions of perl are installed, each program can continued to be tied to the old version until tested against the new, at which time the #! line can be changed to #!/usr/local/bin/perl5.8.9 . The two perls will be completely independent; each will have its own independent set of modules, etc. Nothing will break for 5.8.8 programs while you experiment with 5.8.9 when it comes out.

        Another approach would be to forget the links in /usr/local/bin entirely and just change your PATH to include /usr/local/perl/x.x.x/bin and set the top line of your programs to be #!/usr/local/perl/x.x.x/bin/perlx.x.x .

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