VinsWorldcom has asked for the wisdom of the Perl Monks concerning the following question:

I've done a bit of searching, but I'm not getting the right results so thought I'd pose the question here.

I use Strawberry Perl on Windows and have a few different versions installed (5.8, 5.14, 5.18 32/64, 5.22). I manage them with a simple batch script that changes a directory junction from C:\strawberry to the appropriate Perl. Works great.

HOWEVER, when I switch from one to another, I "lose" all my modules - as expected. In other words, when I CPAN install a non-core modules to version 5.14 for example, when I switch to version 5.18, it isn't there - no shocker. ...

But could it be?

For some pure-perl modules, there should be *no* issue providing there are no backward-compatibility, new feature enhancements used. It'd save a bunch a time installing the same module 5 times for each of my 5 versions. I do have a %USERPROFILE%\perl directory and 'set PERL5LIB=%USERPROFILE%\perl\lib' in Command Prompt environment variables.

But are there implications? I'd install in 1 version of Perl so that CPAN database gets updated, but the other 4 wouldn't - what craziness could ensue? Has anyone done this or is there a better way that I'm missing? My searching keeps turning up local::lib - which is bundled in vendor/lib with Strawberry, but this sounds like what I'm already doing with PERL5LIB.

UPDATE: So I tried it - created a %USERPROFLE%\perl and %USERPROFLE%\perl5 directories. %USERPROFLE%\perl5 is a symlink (mklink in Windows) to a subdirectory in %USERPROFLE%\perl:

VinsWorldcom@C:\Users\VinsWorldcom> ls perl Directory of C:\Users\VinsWorldcom\perl [.] [bin] [..] [5.08.8-MSWin32-x86-multi-thread] [lib] [5.18.1-MSWin32-x64-multi-thread] [5.18.2-MSWin32-x86-multi-thread] [5.22.2-MSWin32-x64-multi-thread] 2 File(s) 7,449 bytes VinsWorldcom@C:\Users\VinsWorldcom> ls -al [...] 01/19/2017 07:52 AM <JUNCTION> perl5 [C:\Users\VinsWorldcom\pe +rl\5.18.1-MSWin32-x64-multi-thread]


PERL5LIB=C:\Users\VinsWorldcom\perl5\lib;C:\Users\VinsWorldcom\perl\li +b

Now for common pure Perl modules I want to share across all versions and I know will work on all versions, I install with:

cpan -j C:\Users\VinsWorldcom\perl\ Module::Name

... and it gets installed to %USERPROFILE%\perl, which has the ..\perl\bin in my %PATH%. Tested and it works fine.

Not sure of the future implications of this or if it's really the way to go. I don't use Perl all that often, but I do maintain a few modules and like to have different Perl version to test them on. Now instead of installing multiple copies of the same module into different Perl site directories, I install it once in a common place and all Perls can run against it and test. Limited use case, just wondered how other developers more experienced than I would handle something like this.

Replies are listed 'Best First'.
Re: Common module lib across Perl versions on same system
by dasgar (Priest) on Jan 18, 2017 at 21:48 UTC

    David Farrell started a new project called berrybrew that was leveraging the portable editions of Strawberry Perl to provide something like perlbrew for Windows. See here for his blog post about it.

    Someone else, stevieb, forked the project to add other functionality. According to his blog (see here), he merged his changes back into David Farrell's code base.

    Although, I haven't used it yet myself, I think that berrybrew could provide most of what you want to accomplish. Since you already have Perl versions installed, I'm not sure how to get berrybrew to pick up and work with your Perl installations. Perhaps you can submit a ticket and get help/suggestions on how to do that from David and/or stevieb.

      Thanks. I've heard of berrybrew, but I was under the assumption is just helped manage different instances of Perl - which I do already. It'd still have the same issue of having to install non-core modules in each version of Perl, correct?

        stevieb here, the person who took over and now maintains berrybrew (thanks for the mention, dasgar!).

        At this time, there is no built-in way to manage external lib directories outside of each Perl instance, but it is on my roadmap (after I get my RasPi work completed).

        Personally, I like each instance to have its own installation of modules, but I digress. It's been requested of me to build in the ability that you're asking for, and as I said, it's on the roadmap. For now, you can do what you're doing, or shift out @INC (unshift @INC, '/path/to/libs'). Some modules will break, others won't.

        If you want an easy way to install a module on all Perl instances with berrybrew and avoid using a single lib dir:

        berrybrew exec cpanm Module::Name

        That'll install the module on all installed Perl instances. If you have a module to install but it won't work on some version, I've added in the ability to exec on certain versions only (NOTE: no space between the perl versions!):

        berrybrew exec --with 5.24.0_64,5.10.1_32 cpanm Module::Name

        If you have any problems or issues, or want to discuss options on how you'd like to see a lib option be implemented, feel free to open an issue on the berrybrew link above (my github), or message me here and I can send over my email address.

        update: To boot, if you're working with Strawberry Perl portable editions, you can incorporate them into berrybrew by copying/moving the instance directory into c:\berrybrew directory, and ensure that it is named exactly the same as one of the entries in berrybrew available. Thereafter, you can clone it to whatever name you want. I did not get as far in the Perl registration logic to allow just dumping any old directory into the berrybrew dir and have it auto-register, but that feature isn't far off either./update

Re: Common module lib across Perl versions on same system
by fishmonger (Chaplain) on Jan 18, 2017 at 22:49 UTC

    If you're installing pure perl modules, then using a common install location will be ok for all perl installations. But that won't work if you're installing non pure perl modules. In those cases, you'll need to install/build them separately for each perl version.


    Also, if you have multiple users, then you would not want to install the modules under %USERPROFILE%. Instead, you'll want to install them in a location where all users can access.

      I think perls do have a built in support for both architecture-dependant and version-dependant directories (and both) in @INC. At least, I can see that support in lib. If I run the (private) sub lib::_get_dirs using
      perl -le "require lib; print for lib::_get_dirs()"
      I see:
      /MSWin32-x64-multi-thread/auto /MSWin32-x64-multi-thread /5.24.0 /5.24.0/MSWin32-x64-multi-thread
      These are subdirectories for each directory you add with use lib, that also get added to @INC.

      So... version dependent library roots are defenitely possible in a common library directory tree.

      Thanks. Understood about XS modules - I know those won't work. This is on my own Windows box for my own development so no worry about %USERPROFILE% - not sharing with other users.

Re: Common module lib across Perl versions on same system
by Anonymous Monk on Jan 18, 2017 at 23:57 UTC

    There is a good chance you're thinking of File::FindLib - Find and use a file/dir from a directory above your script file

    Not exactly better than PERLLIB/PERL5LIB, just a different way to add to @INC :)

Re: Common module lib across Perl versions on same system
by soonix (Canon) on Jan 21, 2017 at 14:34 UTC
    What about version incompatibilities? Not all modules run under all perl versions, or not the same version of a module can be installed under all perl versions. So you'd have to install under all perl versions anyway. My suggestion would be a minicpan or a variant thereof.