Re: Development version of a script?

[ELISHEVA]

Perl gives you at least three different ways to dynamically choose what file Perl loads:

    my $module=My::File;
    my $filename="My/File.pm";

    do $filename;
    eval `cat $filename`;
    eval "require $module";

The difference between them is that

• eval qq{require $module} can only be called once per program because it is designed for loading code that might barf if you try to load it twice in a row, and of course, to avoid unnecessary recompiling of module. You have to run this code as eval string because require needs a bare word, not a quoted string, for a package name.
• do can be called multiple times, if that is what you need. Like require it uses @INC.
• eval, like do can be run multiple times. The biggest difference from do is that it can see variable values set in the calling environment. There are certain situations where that might be an advantage - for instance in a template file. However, in most cases it is likely to cause unwanted side effects. Another difference is that eval cat ... doesn't use @INC to find the file. If the file is coming from your home directory that is good. If it is meant to be stored in directory findable via @INC then you are doing things the hard way. Another disadvantage of C<eval> is that it can't spit out file names and line numbers if there is a problem reading the file

For more information see require, do, and eval.

One additional thought: If you have 40 variables that all co-vary together depending on context (development vs. production), perhaps you might consider bundling those variables in a configuration object/class. That would make any future work with these variables (in particular additional setting sets for testing purposes) much much easier to manage. 40 of anything is not a small number and is hard for the human eye to check and recheck. It is important that you use code structure/data organization as much as possible to ensure that they are set up as a group. If you decide eventually to go the object route, you might also want to consider using YAML to store the settings. The data files are very easy to write by hand (and read) and they can be loaded and dumped with ease.

Update: revised pros/cons of eval - not using @INC can sometimes be desired.

Update: added YAML suggestion

update: changed quotes to backticks on eval

[kurt2439]

I must be missing something simple, or else poorly explained my problem.

When I use any of the methods you guys have explained, I get many compilations error about explicit package names -- so perl is not seeing the file I am trying to include with those variables declared, or else they are out of scope? This was from the require perldoc -- I know it is mentioning the reverse case of what I am doing, but perhaps still relevant

The file is included via the do-FILE mechanism, which is essentially just a variety of eval with the caveat that lexical variables in the invoking script will be invisible to the included code.

Thanks for the tip about including my variables in an object -- it's a little over my head at my current perl level but I will put it on the list of things to check out

Here is the most basic reference to my code so you can see two of my trials of your suggestions

#require ::usr::local::bin::ebook_distributor_DEV::ebooksend_config;
eval "cat /usr/local/bin/ebook_distributor_DEV/ebooksend_config";

[ELISHEVA]

No you aren't missing anything - my bad. The eval cat option should be using backticks, not double quotes, e.g. eval `cat myfile.pl`

My apologies.

If that doesn't help then perhaps you could show a reduced version of your whole set up using just 1 or two variables. Even with the backticks, to get this to work you must take care with how you declare your variables. You will need to declare your variables in the calling script. If you declare them as "my", your config file should merely set variables and not declare them (no my). Alternatively you can declare your variables in both the calling and config script if you use our.

[kurt2439]

I was being too dependent and not thinking about the code you were giving me to run -- should have caught your meaning and put in the backticks...

Now I am understanding you -- I was trying to completely remove the variables from the main script, but I see what you mean about needing them declared in the main script and then just setting them in the "config" file. I haven't tested but I get it now -- thanks!