CODEWITHSUNDEEP
perl
CWRules
CWRules

Reputation: 87

Block inclusion of a Perl module unless explicitly included

I have a Perl application which is used in two contexts: It can be used as a diagnostic tool which displays information about a system, or as a testing tool which sends Modbus commands to that system. The problem I have is that allowing the user to send commands to the system in a diagnostic context is a potential safety risk, so I want to create two executables: A testing version that includes the Modbus module and a diagnostic one that does not.

My current solution is to include the Modbus module like this:

BEGIN { eval { require Modbus; }; Modbus->import; }

This only includes the Modbus module if I use the option -M Modbus while building the .exe with PAR Packager. The issue with this approach is that it fails unless this is the only place where Modbus is imported. So if another developer who isn't aware of this risk comes along, it only takes one require statement to bypass this fix.

Is there a way for me to prevent a specific module from being included in the executable unless I explicitly want it to be (either with the -M option or some other method)? I've been trying to figure something out with Devel::Hide, but haven't had much luck. All the solutions I've found so far fail the "other developer who doesn't know about this" test.

I'm using Strawberry Perl 5.20.3.3, but I can upgrade if necessary.

Upvotes: 3

Views: 129

Answers (2)

Eliyahu Skoczylas
Eliyahu Skoczylas

Reputation: 359

Having read through your comments, it seems that you're not going to be able to enforce correct usage. (You gave examples how the module has already been misused by people sidestepping your build process.) I would suggest an alternative approach.

Document the problem at that place where someone would find a workaround.

In other words, if some other developers is going to look at the code or at the build to see the name of the missing module, let them see a warning about the dangers right there. Put a comment block explaining why the Modbus module should only be used when diagnostics are disabled or filtered. Make the build's failure put a warning right there at the same place as the name of the missing module; use a die "Modbus should not be used when user interaction is enabled."; or something similar to convey the message in the same place where the other developer would be looking for the solution.

Ultimately, you can't force someone to use your build tools, but you can try to educate them while they're trying to work around you, instead of documenting the problem somewhere else that they might not see.

Upvotes: 1

brian d foy
brian d foy

Reputation: 132820

When I've done this sort of thing, I've created a small module that is included if it is present and not included if it is not:

 eval { require MaybeItsThere }

In my Makefile (or whatever build system you want), I have targets for development and production builds. One of the subtasks for the dev build creates that MaybeItsThere file. It can also set whatever it needs for PERL5LIB and so on such that only the dev build can load it.

However, as you say, the enterprising developer can quickly find out what they need to do to get the features they want.

Upvotes: 2

Related Questions