Re: Change Namespace of Package
by haukex (Archbishop) on Sep 14, 2019 at 07:03 UTC
|
It sounds like you don't need to use both version 7 and 8 from the same script, which makes things easier (if you did, that'd make things pretty complicated). You could install the modules to different, custom library paths. Hopefully, the modules use one of the standard Perl installation procedures: If it's ExtUtils::MakeMaker, run perl Makefile.PL INSTALL_BASE=/path/for/v7 resp. /path/for/v8 (the paths where you want to have the libraries installed); if it's Module::Build, run perl Build.PL --install_base /path/for/v7 resp. v8. Then, in your Perl scripts, you can point them at the correct library path, for example with use lib '/path/for/v7/lib/perl5' before loading the module.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
This is exactly what I needed! I tried for a while to only install only one version to a custom installation location but had issues. Once I gave up on that placed both versions of the package in a custom location (as you recommended) things worked perfectly! Wahoo!
Much thanks!
| [reply] [Watch: Dir/Any] |
|
I prefer to install two builds of Perl rather than much with additional include paths. It's super easy with perlbrew, and you don't have to worry about setting the environment right or about different dependencies or version of dependencies, etc.
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] |
|
|
|
|
Re: Change Namespace of Package
by stevieb (Canon) on Sep 14, 2019 at 20:15 UTC
|
In addition to what haukex said, you could also set up different Perl installations for each version (ie. install a specific version of Perl, clone it, install v7 on one instance, v8 on the second instance, and switch between them when testing/working with one version or the other). If the user-facing APIs haven't changed between versions of InfoBlox, your scripts would work seamlessly between Perl instances. Otherwise, you'd simply have to either have an argument that determines which version you want to operate against, or just have separate scripts per version.
It would help if you could let us know what Operating System you're running, along with an example script showing how you're using the module.
A briefing of your development practices would also be beneficial here; for example, do you have to make changes to your scripts in order to use the differing versions of this module?
| [reply] [Watch: Dir/Any] [d/l] |
|
A second perl instance was something I had considered before I made this post but it seemed extreme so I thought I would ask for help first. I am glad I did because what haukex wrote fixed me right up. I am running to different scripts depending which server I need to reach out to. Thanks for the help.
To answer your other questions my production environment is Red Hat but once I started messing around with the initial package I needed a development environment to play with. I ended up installing Strawberry Perl on my Windows workstation for that purpose and while it wasn't ideal, it worked well enough.
| [reply] [Watch: Dir/Any] |
Re: Change Namespace of Package
by shmem (Chancellor) on Sep 14, 2019 at 21:52 UTC
|
Adding to what haukex wrote, you could get the version of the module from the command line, if you wrap command line processing into a BEGIN block:
use strict; use warnings;
my %options;
BEGIN {
use Getopt::Std;
getopt('v', \%options);
die "invalid value for -v switch\n"
if ($options{v} !~ /^(?:7|8)$/);
my $path = "/path/for/v$options{v}/lib/perl5";
unshift @INC, $path;
}
use Infoblox; # /path/for/v$options{v}/lib/perl5 will be searched firs
+t
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] [Watch: Dir/Any] [d/l] |
Re: Change Namespace of Package
by NERDVANA (Deacon) on Sep 14, 2019 at 23:50 UTC
|
A perl package's name comes from the "package XYZ" declaration. If you change this, and change the directory name, and change every use of the Infoblox:: namespace... you have a good chance of it all working.
# install Infoblox version 7 first,
# then in the perl lib directory where it installed:
find Infoblox -print0 | xargs -0 \
sed -i -e 's/Infoblox::/Infoblox7::/g'
mv Infoblox Infoblox7
If there is also a Infoblox.pm, then run sed on it too.
sed -i -e 's/package Infoblox/package Infoblox7/g' \
-e 's/Infoblox::/Infoblox7/g' \
Infoblox.pm
mv Infoblox.pm Infoblox7.pm
Then, give it a review for other uses of the word Infoblox to look for any others that might need to change:
grep -C 4 -R 'Infoblox[^7]' Infoblox7.pm Infoblox7 | less
Then... give it a try. If it works, then you can install the new Infoblox alongside. (and maybe decide to rename it too, since they vendor wasn't helpful enough to version their module)
If it doesn't work, then fall back to the other lib directory strategies proposed here. | [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Change Namespace of Package
by Anonymous Monk on Sep 16, 2019 at 21:27 UTC
|
If you are using a Un*x-like environment, the source filename bash-command is an easy way to run settings-files which establish environment-variable exports such as PERL5LIB, PATH, and the shell command-prompt (to help you remember what settings you are now in). You can even alias the perl command itself. Remember to check-in these settings files in version control. | [reply] [Watch: Dir/Any] |