Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re: Packaging Perl Programs (is) Painful

by BrowserUk (Pope)
on Sep 04, 2010 at 14:58 UTC ( #858880=note: print w/replies, xml ) Need Help??

in reply to Packaging Perl Programs (is) Painful

Personally, I think the entire premise of what you are trying to do, and the way you are going about trying to do it is completely wrong.

One of your stated aims is avoiding the installation of perl on every workstation. But, by packaging your apps in this way and running them from a remote share, you are effectively causing Perl to be shipped across the network and installed locally, before the app can start to run. And that process has to be repeated each time each person runs an app. Even when they are re-running the same app a few seconds later.

Also, you complain that one of the packagers doesn't follow use lib ... directives. But lib is a hack. A useful hack intended to bypass silly administrative decisions, but still a hack. If you are responsible for writing and deploying apps company wide, you should certainly have the authorities and permissions to install packages into the production Perl environment. And if all your packages were correctly installed, you wouldn't have to rely upon lib, and the packagers wouldn't be having this problem.

But finally, if you are going to deploy the apps by placing them on a network share, why bother packaging them in the first place. It makes no sense.

If instead, you shared your production Perl installation, with all the packages required by all your apps correctly installed. And place the top-level .pl scripts (or some placeholder .cmd files if some local setup is required), within that installation. Then your users can run those applications from that shared installation. They will load faster because there is no need to transmit, unpack and install everything into the local file system every time.

It makes it easier to test, easier to deploy, easier to control access (via permissions, groups etc.), and you avoid the packaging requirement completely.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Packaging Perl Programs (is) Painful (shares)
by tye (Sage) on Sep 04, 2010 at 18:59 UTC

    I've done this quite effectively. I simply 'shared' the directory where I had Perl installed and wrapped the Perl script as a *.bat file that knew how to launch perl as \\mymachine\perlshare\bin\perl. Then when people (inevitably) copied the *.bat to wherever they put their little utilities, it continued to work.

    I even allowed people to avoid relying on my Perl installation if they wanted to. My *.bat wrapper (based on what pl2bat does) would try to run a local "perl" first and only run \\mymachine\perlshare\bin\perl if no local "perl" was found. In a few cases where my script required non-core modules, I even made it smart enough to try to 'require' the needed module(s) and, if that failed, it would just silently exit in a way that would tell the *.bat wrapper to launch via my shared perl.

    - tye        

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://858880]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (4)
As of 2018-06-23 13:12 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.