|
Re: Replicate Perl setup
by Fletch (Bishop) on Dec 10, 2021 at 13:37 UTC
|
The CPAN module has an autobundle command which will write a Bundle::Snapshot_YYYY_MM_DD_XX (the last XX being a counter) containing a list of modules and revisions which are installed that you can use to have it reinstall the same set. You could use that to prime an install of the same base perl version somewhere else which (depending on the OS and compiler state) should be more or less identical.
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply]
[d/l]
[select] |
|
|
this looks promising, thanks!
| [reply] |
|
|
Does this work even with modules install with cpanm (cpan minus) ?
| [reply] |
|
|
It uses the list/manifest of installed modules which is written by the module’s make install process which is independent of what you use to install. So long as you’re not (say) copying things into the lib hierarchy by hand it’ll find things.
Edit: Afterthought if you’re asking can cpanm install a bundle module list generated by CPAN . . . That’s actually an interesting question and I’m not sure. The bundle pod is written into the .cpan config dirs and I don’t know if minus can/would look there; but if it (App::cpanminus) can handle them I’d bet it would. Personally when using this feature I’m bootstrapping a new Perl install and I’m expecting minus to be one of the things to get installed by said bundle so it’s not anything I’ve tried.
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply]
[d/l]
[select] |
Re: Replicate Perl setup (Building and Installing Perl References)
by eyepopslikeamosquito (Archbishop) on Dec 11, 2021 at 00:43 UTC
|
See here for one primitive way to do this type of thing.
Valuing reliability and lower support costs over flexibility, we installed our version of Perl,
along with our stable set of CPAN modules, on many different customer machines --
without affecting other versions of Perl that may be installed on their system,
and without requiring root permissions.
BTW, my manager back then had previously worked at Microsoft, where a broken build cut
onto millions of CDs was a total disaster ... their build team became paranoid,
going to incredible lengths to avoid breaking the build;
they'd even experienced cases where simply installing an OS patch broke their build! ...
so their build machines were quarantined from the network, with only the build team allowed to touch them.
Reference
References Added Later
Examples of building Perl from source:
Windows and Strawberry Perl
- Strawberry Perl (wikipedia)
- Mingw-w64 (wikipedia) - gcc-based C/C++ compiler used by Strawberry Perl (Note: MSYS2 ("minimal system 2") is a software distribution and a development platform for Microsoft Windows, based on Mingw-w64 and Cygwin ... MSYS2 and its bash environment is used by Git)
- Cygwin (wikipedia) - a Unix-like environment and command-line interface for Microsoft Windows (uses cross-compilers from Mingw-w64 project)
- Strawberry Perl (official site)
- Strawberry Perl (github)
Platform-Specific perldoc Notes
See Also
| [reply]
[d/l]
[select] |
Re: Replicate Perl setup
by LanX (Saint) on Dec 10, 2021 at 13:22 UTC
|
> to copy the modules of the specific version they are in from the old machine to the new machine
That depends on hardware and OS.
On windows copying the directory tree is sufficient, at least with ActiveState.
I think I heard you can do similar things on Linux if the OS and hardware are sufficiently close, but you'll have to replicate some ENV-settings too.
It mainly boils down to the binary compatibility of installed XS modules, otherwise they need to be recompiled.
| [reply] |
|
|
On windows copying the directory tree is sufficient, at least with ActiveState.
This is true, but AS licensing agreements from years ago prohibited that for actual product shipment. I don't know what current AS licensing says for a re-distributed product. I suspect potential legal trouble if this is done for end-product distribution vs perhaps in-house use.
At the time, I bought a Perl Dev Kit license and generated an .exe file for just that legal reason. Of course the Dev Kit has been discontinued.
AS did have some tools for "cloning" an installation. You ran a utility to make an XML file. You installed Perl directly from AS (no binary distribution allowed) on the target machine. Then there was a utility that used this XML file which was supposed to re-create the environment on the target machine. I had trouble with that and I think many others did too.
The new AS way is to create an account on their site and have AS build a version for you with the modules that you need. The result of this is an installable MSI file or equivalent in the Unix world. That AS built version (which includes XS binaries for your platform) can be freely re-distributed without restriction. In the Windows world, this is good. There of course can be complex issues with multiple Perl versions on any platform.
| [reply] |
|
|
| [reply] |
Re: Replicate Perl setup
by davido (Cardinal) on Dec 10, 2021 at 16:25 UTC
|
This may also be solved using containers. Docker + Carton (for dependencies) + make, for example.
| [reply] |
|
|
This is how the cool kids do it.
| [reply] |
Re: Replicate Perl setup
by karlgoethebier (Abbot) on Dec 11, 2021 at 18:13 UTC
|
Couldn’t you clone the machine(s)? In the last company i was with we had some success with this procedure. Regards, Karl
«The Crux of the Biscuit is the Apostrophe»
| [reply] |
Re: Replicate Perl setup
by perlfan (Vicar) on Dec 12, 2021 at 23:01 UTC
|
> I'm afraid to install the newest modules on the new machine in case there are incompatibilities
Don't be a 'frady cat. No matter what you use an environment - docker, perlbrew, virtualbox, etc - see how far you can get with just a test environment; installing the packages from CPAN or, better, the local package manager. Fix your code where you need to. Once you get that working, your life will be a lot simpler and you'll see how silly being "afraid" actually is. I'd rather be seeing you post questions here regarding the fixing of your code than to enable you to just live in some false sense of fear. | [reply] |
|
|
One caveat from experience (and if you search through my post history I'm probably a broken record about this):
Never use the OS' perl and package manager if you don't have 100% control over the OS. With today's container solutions that's less of an issue (since you're more likely to have full control over the image inside), but if you're still on bare metal and at the whim of (say) a central IT department you're going to get bitten at some point. They're going to upgrade your perl and/or packages underneath your application without your knowledge or consent at some point (Murphy sez) and then you're going to be the unfortunate schmuck on the hook to unbreak what they've just broked (because you didn't plan on Foo::Bar suddenly throwing an error because there was an upstream bug your existing code exercised but wasn't handling that's now fixed).
Always roll and maintain your own application install somewhere you control and use that instead of /usr/bin/perl or whatever.
Make sure to shebang everything #!/usr/bin/env perl rather than an explicit path then manage PATH to find what to run (that also allows you to test and migrate to a new version without editing all your scripts).
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply]
[d/l]
[select] |
