Disclaimer: what follows is personal opinion, and may not reflect the views of ElectricCloud-the-company!
1) The preferable solution is just don't add CPAN modules to ec-perl. Find another way to solve the problem instead! It used to work pretty well on all but Windows systems, but time has marched on... There are several reasons why I do not recommend trying to add modules to ec-perl:
a) As soon as you add the module to ec-perl on one of your agents, you have now made your life more difficult -- because now, in order to be able to run your ElectricCommander procedure or process on any other agent, you'll have to repeat that process on that other agent. And then you'll have to do it again each time you upgrade the ElectricCommander/ElectricFlow software on any agent. And as the number of agents increases, the amount of work you'll be doing just to add that module in and keep it installed and working grows larger and larger and larger -- and then of course, when you get promoted or move on, somebody else will take over, and probably they won't know about CPAN and your module, and so when they install an new agent or upgrade one, everything will break, and everyone gets involved to try to reverse-engineer what you did in order to fix the problem... and when all your team members figure out what you did, your name will be cursed and written in the Great Book in Hall of Shame... it's just ugly, ugly, ugly. Don't go there. There are better ways.
b) However, if you choose to ignore the advice above, you may find that it's just not possible to make the CPAN module work with the relatively-old ec-perl version (but before you jump to this conclusion, it's worth checking carefully to make sure you don't have conflicts between ec-perl and your system perl -- for example, if you just run the CPAN commands without setting your PATH to the ec-perl perl/bin directory, you're probably running your system CPAN commands!).
For various reasons (mainly breaking changes introduced in various perl versions), ec-perl remains at version 5.8.8 and I notice that the most recent test information for the ini files perl module you mention was tested on 5.22! That's quite a delta, and it may require that you upgrade a lot of the ec-perl modules in order to get the current version of the CPAN module to run -- which then runs afoul of the afore-mentioned breaking changes (in other words, getting the current version of a CPAN module and all its dependencies upgraded and working may end up breaking core functionality in the ec-perl implementation -- in particular, SSL changes have been encountered by customers).
c) Assuming that you can find an older version of the CPAN module that is known to work with 5.8.8 versions of perl, the next challenge comes up in getting the infrastructure for building and installing that module in place. Many modules are "pure perl", meaning that they have no compiled C language or any other type of code -- these modules should be able to be installed without too much trouble - just make sure that you find appropriate versions (i.e. pure perl, and able to work with 5.8.8) of all the dependencies that the module has and install those first. However, if your module has any compiled code, then you'll need a C compiler (or whatever language your module needs) that works on your agent's OS, and you'll need to get all the necessary development libraries required to compile that module. On Linux this is not usually too tough to do, but on Windows, you'll need to match whatever compilation tools were used by Electric Cloud when ec-perl was compiled and built originally. Since that information is not published, that means that for all practical situations, it's simply not possible to build a non-pure-perl module for ec-perl on a Windows system.
2) Ok, so if you can't use CPAN to add a module to ec-perl, what are the alternatives? There are several approaches, and I'll note some of them below:
a) Why are you using ec-perl in the first place? Unless you need deep access to the ElectricCommander API, why not just use the system-provided perl? That perl, presumably, will be more recent, and you should find that CPAN will work more effectively. And, if you do end up requiring a binary (non-pure) module, at least the system-provided perl should have the necessary toolchain (compilers, libraries) readily available to build that module. For "shallow" access to the API, you don't need ec-perl -- just have the system-provided perl do something like "system("ectool setProperty my-problem-answer 42");" or similar. And with recent versions of the ElectricCommander server, your system perl can simply use the REST API to interact with the server.
b) In many cases, if option (a) above won't work for you, you can solve most of the challenges by simply not using CPAN directly, and instead manually extracting the module you need (and any dependencies) into some directory or folder that all your agents can see. Then adjust you include paths in the perl code to search that location. This is actually how many of the provided plugins for ElectricCommander handle the need for additional perl libraries.
Here's a rough outline using the ini files CPAN module as an example. First, locate the module documentation page on the CPAN web site, and note the download link (on the far right-hand side of the page). Click on that to download the module. It's a compressed tar file, so I'd use a Linux system to extract the contents. An examination of the resulting folder shows that the bulk of the module are tests (which is great, I love when modules are clearly well-tested!), and it also shows no signs of any language other than perl (in other words, it seems to be a pure perl module). The only file I'm really interested in is the contents of the "lib" directory -- which contains nothing but Config/IniFiles.pm -- so that's the file that I need to put somewhere to make it available for my agents.
But before you go finding a shared folder or filesystem that you can use for that purpose, let me suggest a better approach. The problem is that you don't want to introduce a dependency on a shared filesystem if you don't have to. And we don't, because we have something else that's available to all agents that we can use instead -- a property. In a nutshell, what if we just load the file IniFiles.pm into a property somewhere, and then rather than the statement "use Config/IniFiles" in my ec-perl script, just insert a property reference (e.g. $[/myProject/IniFiles.pm] ) into the script to have the perl module expanded inline? That technique is used in many of the plugins, and is my preferred approach. Note that you may have to do the same with any dependencies the IniFiles.pm module may have, and you'll be responsible for the ordering of the inclusion - but's that's way, way easier than fighting with CPAN or shared filesystems!
c) Finally, what to do if the module you need is a non-pure module, in particular on a Windows system where you have no access to a compiler and libraries that are compatible with the provided ec-perl, and you cannot use the system-provided perl, and no other interpreters will do or are available? Well, I'd suggest that you go back and try to fix one of those things, but if all else fails, and your choices are certain death or trying incredibly ugly (and potentially risky) hacks, then consider borrowing the non-pure compiled module from the 5.8.8 strawberry perl distribution for Windows. You'll have to manually copy in the module you need (CPAN won't work) from that distribution, cross your fingers, and test thoroughly - I've had limited success with that, but in most cases the binary modules contained therein seemed to work with ec-perl, at least back in the 4.2.x ElectricCommander versions. Avoid this if you can - with the recent versions of ElectricCommander and the REST API, there's really little excuse to foist this sort of hackery on whomever will inherit your work later on!