I am still using Perl 5.24, the last release that AS (Active State) supported PPM. Haven't really had the impetus to make a migration to either the new AS way or to Strawberry Perl. It is hard to overcome inertia unless I am working on a new big project. I have however built AS MSI's for a couple of other folks who have successfully installed them. The AS new process has evolved and I think they've got a lot of the low hanging fruit fixed by now. When I get serious about migrating, I may go again with AS (Active State). For me, having the ability to easily clone and distribute my development environment is a good thing - that is one of the problems that the new AS process fixes.
Anyway, I wouldn't rule AS out. There are some nice benefits to their new process - one big disadvantage is lack of support for more than latest 2 releases. I haven't made up my mind yet about it. If you want to stay with AS, I could probably find some tips for you of things I ran across while forking my tree and making custom Perl builds.
Update: A better description of the problems that you are having would be very helpful. In general, your program will work the same on either an AS or a Strawberry installation of the same Perl version. Sometimes when migrating up a version or 2, Perl code changes are required. A feature may become deprecated and then ultimately removed from a succeeding version. I personally do not use experimental features in production code. An issue like "doesn't search script directory by default" is a Perl version specific issue and the same thing will happen on AS or Strawberry.
Other problems can arise with installation of modules past whatever comes with the installation you started with (there will be of course all "core" modules + some number of additional modules pre-installed). Adding more modules to that mix requires extra steps. The old PPM method from AS was pretty "bulletproof" - meaning that you would be sure that the module that you are adding passed all tests and it also installed very quickly since no testing on your machine needed to be done. Using cpan or cpanm to install a module is a much more time time/compute intensive thing and you are not guaranteed success like you were with PPM. So there can be issues where a module's installation fails or only partially works. The number of possible ways for module installation and testing to go wrong is so huge, you will need to provide a concrete example of a problem. You say: " transitioning to an earlier Perl version of the Strawberry version" - I am not sure what that means although I have read your sentence multiple times!
You will find that installing a module with cpan or cpanm can take a long time mainly because of running a bunch of tests to make sure that the module is working. The new AS process moves all of the testing (and possible compiling) work to the AS server farm. What might take my personal machine an hour, might take 5 minutes on the AS servers. So far I have only worked with the initial building of an AS system (what you are doing is essentially adding to the list of "pre-installed" modules). There are some AS utilities (that I don't know how to use yet) that can modify an existing system and be much faster than running cpan.
Update Again: Looking at the Active State site, they have versions 5.36.0 5.34.0 5.32.1
Strawberry's site has 5.32.1.1 from Jan 24, 2021 as the latest.
What version(s) are you trying to use?
If you are already at a more recent release of AS, why would you want to go backwards?
I do see the new EULA from AS that says only "one instance at a time" - that could be the issue?
| 