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?
In reply to Re: Strawberry Version
by Marshall
in thread Strawberry Version
by ephemeralx
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |