Yes, I’ve read the documentation at the link you provided.
Since you’ve copied @scottr and @shanew, I should clarify my goal, which really is this:
Find a suitable path to upgrade from ActiveState perl 5.24 to ActiveState 5.28 (and beyond)
This goal entails several objectives:
- find a means to replace the functionality of ppm, which is no longer available
- upgrade my own personal perl Windows 10 environment
- recommend an upgrade path for my client
My client has several small perl applications that run on Windows and Unix. For the most part, these are scripts which run as services that monitor the environment and take certain actions. For example, some scripts frequently access a database, some access LDAP servers, some just ping machines to see if they are online or offline. The scripts may send out email notifications.
These scripts need 40+ non-core modules.
My client packages their perl scripts and installs them at a client site. They may or may not have internet access from the account and machine they do the install from. Or admin access. So, offline installation is a requirement.
Typically, they have relied on perl either being installed on the customer machines, or have been permitted to install it. If the customer is using an older version than what is required for their scripts, they negotiate an upgrade with their customer to bring their version up to the necessary level.
To deal with offline installs, my client downloads the tarballs for all the modules they use and then deposit them onto the customers’ machine – after which they have used ppm to install them into the customers’ site lib.
So far, I have found two upgrade paths that seem workable:
- upgrade to Strawberry Perl and start using cpanm (in place of ppm).
- upgrade to ActiveState Platform and start using state tool (in place of ppm).
Path 1 results in a fairly painless upgrade and minimal impact on my clients’ current workflow. The just start using cpan and/or cpanm instead of ppm. I had quick success installing Strawberry Perl 5.28 and getting it to work with their software. I had minimal problems installing their 40+ modules.
Path 2 is one I’ve been exploring now for almost two weeks. I’ve run into various obstacles:
- wasting time on state push, because I didn’t understand when or why to use it, the error messages didn’t help, the documentation didn’t help, and the email I sent to email@example.com went unanswered.
- problems with dependencies in 5.28
- slow build times for 5.28 once I had a lot of dependencies; on the weekend builds were taking an hour
- low productivity for 5.28 because every dependency change triggered a full rebuild
- unable to run cpan or cpanm in order to download modules or tarballs
- once I saw how builds were kept isolated by installing them in separate folders under %APPDATA%\Local\ActiveState, I ended up doing a lot of head scratching trying to figure out what this might mean for my clients’ scripts. It meant going from a system-wide perl install that scripts would use from whatever account they ran in, to a private perl install that must be activated within each .bat file. Will that even work from a script launched by cron? (I think they use pycron on Windows)
Once I got on the Community site and asking questions, some of the mysteries began to clear up. It was recommended that I try 5.32 – that it would build faster (incrementally). That has turned out to be the case. But, I’ve run into a couple of dependency and build issues (which I’ve posted). I’ve yet to get a successful 5.32.1 build with all the dependencies my client requires.
As for my goal of updating my own environment, I installed 5.28 at the system level and had a lot if issues installing all my modules. I got 95% there. But I use TCC (from jpsoft) as my command shell, and although it is a superset of cmd.exe I had issues using it with state tool – not the least of which is that state tool drops you into cmd.exe automatically, even when launched from TCC (with COMSPEC pointing to TCC.EXE). Even subshelling from the ActiveState instance of CMD to TCC doesn’t let you work in TCC without some issues. In the end, I resolved that the best thing to do was always use CMD (or bash, but I’m not that found of bash) when using ActiveState perl 5.28 and above.
I was aware, from the documentation, that TCC wasn’t a shell that was supported. Nonetheless, it is the shell I’ve been using for decades, I really like it, and I am loathe to abandon it.
The think is, none of these issues affect me when I use Strawberry Perl. It was about as smooth an upgrade as I could ask for. I simply started using cpanm and off I went.
So there you have it. Honestly, not a pretty story. I’ve been a user of ActiveState perl and python for a couple of decades. I even visited your office in Vancouver to see some of my former Cognos colleagues around 2000 I think. I’ve trying to keep an open mind, but the difference in the upgrade paths is just too hard to ignore.