In my environment I have an isolation script, git-like. I will call it 'blah' for the sake of example. There are identically functioning version of blah for cmd, sh, and other environments as needed.

• $BLAH_ROOT/blah shell sets up my operating environment and opens a shell window, via the shell command in my operating environment.
• $BLAH_ROOT/blah frobnitz sets up my operating environment and calls frobnitz in my operating environment.

Basically, I configure the environment to an expected state prior to kicking off the actual worker scripts. The only thing that changes between production, test, my development, your development, and Joe Blogg's development environments are the settings configured in the isolation scripts (blah.cmd, for example). Given this setup, you should be able to isolate your environment from the operating system to be able to interact however you wish it to - including totally ignoring your vendor's minimal installation of perl.

From the OS side of things, if you need to launch something from, for example, a shortcut, you would preface the invocation with the isolation script appropriate for the environment you are launching your real script under. blah plackup myapp.psgi, as an example, would launch your myapp.psgi plack application in the environment configured by blah. You need to change the environment (or launch it in dev, or change the location of a resource, or....), you use a modified isolation script.

You can even take it so far, if you wish, as to pass in the location of all of your resources (databases, data locations, ports, hostnames, and so on) via the environment through your isolation script. As an example, I have a CSV set of data that I use for my user database in development, and in production I use a corporately-maintained LDAP store. The only change is a modification to an environment variable pointing to a different data source (see URI::db and DBD::LDAP). No change in the code, only a change in the data source.

See also twelve factor app.