RT Init in custom shell scripts

Hi,

I am in the process of setting up a new RT-3.8.5 server to replace our
old 3.4.5 server. While testing some of our custom shell scripts (not
scrips), I had a problem with RT::Init failing while it was loading the
additional plugins that we have installed. I traced the problem to
RT::InitPluginPaths which only adds the plugin’s lib path after the
LocalLibPath, and will only do it IF that LocalLibPath is already in
@INC.

My installation is based on the Fedora rpm, which installs RT into the
vendor_perl area of perl’s @INC lib path so all standard RT modules are
found by default. I guess I expected RT to automatically include the
local lib path in @INC since the variable is defined in RT.pm, but I had
to manually include it in my scripts:

use RT;
use lib $RT::LocalLibPath;

Is this expected?

One possible fix is to append the plugin list of @lib_dirs to the end of
@INC even when $RT::LocalLibPath is not found in @INC, in the
RT::InitPluginPaths function, instead of the current behavior of only
appending it if and when $RT::LocalLibPath is in @INC.

~Jason

/------------------------------------------------------------------
| Jason A. Smith Email: smithj4@bnl.gov |
| Atlas Computing Facility, Bldg. 510M Phone: +1-631-344-4226 |
| Brookhaven National Lab, P.O. Box 5000 Fax: +1-631-344-7616 |
| Upton, NY 11973-5000, U.S.A. |
------------------------------------------------------------------/

smime.p7s (3.81 KB)

Hi,

I am in the process of setting up a new RT-3.8.5 server to replace our
old 3.4.5 server. While testing some of our custom shell scripts (not
scrips), I had a problem with RT::Init failing while it was loading the
additional plugins that we have installed. I traced the problem to
RT::InitPluginPaths which only adds the plugin’s lib path after the
LocalLibPath, and will only do it IF that LocalLibPath is already in
@INC.

My installation is based on the Fedora rpm, which installs RT into the
vendor_perl area of perl’s @INC lib path so all standard RT modules are
found by default. I guess I expected RT to automatically include the
local lib path in @INC since the variable is defined in RT.pm, but I had
to manually include it in my scripts:

use RT;
use lib $RT::LocalLibPath;

Is this expected?

Usually this gets written (on systems where RT doesn’t live in @INC)
use lib (’/opt/rt3/local/lib’,’/opt/rt3/lib’);

One possible fix is to append the plugin list of @lib_dirs to the end of
@INC even when $RT::LocalLibPath is not found in @INC, in the
RT::InitPluginPaths function, instead of the current behavior of only
appending it if and when $RT::LocalLibPath is in @INC.

This has been discussed internally, but I don’t know if there is a bug
open for changing it.

-kevin

Hi,

I am in the process of setting up a new RT-3.8.5 server to replace our
old 3.4.5 server. While testing some of our custom shell scripts (not
scrips), I had a problem with RT::Init failing while it was loading the
additional plugins that we have installed. I traced the problem to
RT::InitPluginPaths which only adds the plugin’s lib path after the
LocalLibPath, and will only do it IF that LocalLibPath is already in
@INC.

My installation is based on the Fedora rpm, which installs RT into the
vendor_perl area of perl’s @INC lib path so all standard RT modules are
found by default. I guess I expected RT to automatically include the
local lib path in @INC since the variable is defined in RT.pm, but I had
to manually include it in my scripts:

use RT;
use lib $RT::LocalLibPath;

Is this expected?

Usually this gets written (on systems where RT doesn’t live in @INC)
use lib (’/opt/rt3/local/lib’,’/opt/rt3/lib’);

Ok, I see it in a BEGIN block of the other installed rt-* scripts.

One possible fix is to append the plugin list of @lib_dirs to the end of
@INC even when $RT::LocalLibPath is not found in @INC, in the
RT::InitPluginPaths function, instead of the current behavior of only
appending it if and when $RT::LocalLibPath is in @INC.

This has been discussed internally, but I don’t know if there is a bug
open for changing it.

What does that mean, that it is uncertain that it is really a bug or
just that there is no official bug to track it yet? It does sound like
a bug to me since the plugin lib path should be added to @INC regardless
of whether the local lib path is there or not.

Thanks,
~Jason

/------------------------------------------------------------------
| Jason A. Smith Email: smithj4@bnl.gov |
| Atlas Computing Facility, Bldg. 510M Phone: +1-631-344-4226 |
| Brookhaven National Lab, P.O. Box 5000 Fax: +1-631-344-7616 |
| Upton, NY 11973-5000, U.S.A. |
------------------------------------------------------------------/

smime.p7s (3.81 KB)

This has been discussed internally, but I don’t know if there is a bug
open for changing it.

What does that mean, that it is uncertain that it is really a bug or
just that there is no official bug to track it yet? It does sound like
a bug to me since the plugin lib path should be added to @INC regardless
of whether the local lib path is there or not.

It means I’ve had a conversation with other engineers about it and
opinions have been expressed, but I’m not aware of anyone opening a
bug to track it or committing a patch to change the behavior.

-kevin