Strawberry Perl - installing an older version

[kcott]

This is for a $work project. I'm testing the viability of packaging a current application with various versions of Perl on Win10. I've already worked with ActivePerl 5.16.3 and Strawberry Perl (SP) 5.30.0 (both successfully installed). I'm now attempting to install SP 5.26.3 — that's where I've run into a problem and is the focus of this question.

For the SP installations, I have these directories set up:

C:\Users\ken\local\opt\strawberry_perl\5_030_000\install\
C:\Users\ken\local\opt\strawberry_perl\5_026_003\install\

SP 5.30.0 is installed in the 5_030_000 path; I was planning to install SP 5.26.3 in the 5_026_003 path.

When I try to run the SP 5.26.3 MSI, a panel pops up with this warning:

A newer version of Strawberry Perl (64-bit) is already installed.

After clicking "OK" (the only option) a setup wizard panel appears saying it ended prematurely due to an error and that the system has not been modified. The "Finish" button is the only option at this point.

The PATH environment variable has these SP 5.30.0 paths at the start:

C:\Users\ken\local\opt\strawberry_perl\5_030_000\install\c\bin
C:\Users\ken\local\opt\strawberry_perl\5_030_000\install\perl\site\bin
C:\Users\ken\local\opt\strawberry_perl\5_030_000\install\perl\bin

I can remove these — in fact, I half suspect that will be necessary — but I'd prefer not to uninstall the whole SP 5.30.0. I've already installed modules for that and some of the compilations took a long time.

I note there is a "Portable edition"; however, _"perl on USB stick"_ is not really what I'm after. Perhaps that can be tweaked to run under C:\...\5_026_003\... instead of F:\... (F: is typically automatically assigned for USB sticks).

I'm aware there are some applications like Perlbrew (Homebrew? Berrybrew? Other?) but have never used any of these and know almost nothing about them. If any of these can exactly mirror a direct C: drive installation (such as I currently have with SP 5.30.0) they may be worth investigating. Although, if these would be required for the final packaging of the application, I suspect they will be unsuitable; but I'd be happy to look at them as (secondary) options.

Ultimately, I'm after a way to install the SP 5.26.3 (preferably) without losing the SP 5.30.0. Any help with this would be much appreciated.

[As I said, this is for a $work project. For my personal use on Win10, I use Cygwin and Perlbrew. I'm certainly no expert with either Win10 or SP: please bear that in mind in any replies.]

[syphilis]

A newer version of Strawberry Perl (64-bit) is already installed.

I handle multiple versions of Strawberry Perl by installing the portable zip instead of the MSI. Just grab strawberry-perl-5.26.3.1-64bit-portable.zip (or strawberry-perl-5.26.3.1-32bit-portable.zip for 32-bit architecture), cd to

C:\Users\ken\local\opt\strawberry_perl\5_026_003\install

and unzip it.

Having done that, executing C:\Users\ken\local\opt\strawberry_perl\5_026_003\install\portableshell.bat will open a cmd.exe shell with the PATH already set to point at the 5.26.3 installation.

UPDATE:
I can remove these — in fact, I half suspect that will be necessary ...

I believe that won't be necessary - the shell opened by potrtableshell.bat will prepend the pre-existing PATH with the location of perl-5.26.3.
Any other shell that's not created by portableshell.bat will still point to perl-5.30.0.

Cheers,
Rob

[kcott]

G'day Rob,

++ Many thanks. That's pretty much exactly what I was looking for. I followed your instructions and everything worked perfectly.

When I came back to write this, I saw your update. Actually, in my case, removing the 5_030_000 was necessary; although, a simple s/30_000/26_003/ on three lines was all that was required. I also removed the ActivePerl entries from the path. The reason is that if something is not found under 5.26, I want to know about it; instead of a something that I'd previously installed under 5.30 (or 5.16) being silently used — I'm not sure how likely that might be, but now I can be certain it won't happen. I've documented all paths and the changes I've made — probably less than a minute's work to swap to a different version.

So now my PATH looks like this (split up, and a chuck removed from the middle, for ease of viewing):

C:\Users\ken\tmp>echo %PATH%
C:\Users\ken\local\opt\strawberry_perl\5_026_003\install\perl\site\bin
+;
C:\Users\ken\local\opt\strawberry_perl\5_026_003\install\perl\bin;
C:\Users\ken\local\opt\strawberry_perl\5_026_003\install\c\bin;
...;
C:\Users\ken\local\bin

I get the added benefit of only having to start cmd.exe:

C:\Users\ken\tmp>perl -v

This is perl 5, version 26, subversion 3 (v5.26.3) built for MSWin32-x
+64-multi-thread
...

C:\Users\ken\tmp>perl -E "say for @INC"
C:/Users/ken/local/opt/strawberry_perl/5_026_003/install/perl/site/lib
C:/Users/ken/local/opt/strawberry_perl/5_026_003/install/perl/vendor/l
+ib
C:/Users/ken/local/opt/strawberry_perl/5_026_003/install/perl/lib

This is probably not ideal if you want to quickly swap between versions; however, for my current ($work) needs, it's spot on. Thanks again.

[stevieb]

Everything that you've mentioned is the reason behind berrybrew. It does all of that path documenting and management itself. It provides you the ability to switch between versions with a single command (or in newer versions, with a couple of clicks of the mouse as well).

[stevieb]

berrybrew will allow you to install and switch between different versions of Strawberry without affecting your existing installations.

My unreleased, currently being worked on v1.31 branch allows you to do installs, switch and remove from the UI. You can download the installer for that version right here.

Once it's installed, the UI icon will stay down in the task bar icon area. Just click it and it'll show you the various options.

Let me know if you have any questions or problems. It's been a few months since I've worked on it.

[kcott]

G'day stevieb,

Thanks for the reply. I have some questions.

The links you've provided are for an "unreleased, currently being worked on" version. Is there a "released, finished being worked on" version?

I see "... the list of Strawberry Perls available ..." mentioned in the opening remarks, in the available and fetch commands, and in the "Update Perls Available" section. I'm unclear as to what this actually refers. Are all versions on "Strawberry Perl Releases" available? Does "we'll update the local perls.json file" refer to something that berrybrew does dynamically, or an indication of something that will be made available in some later release?

In the "Configure Root Directory" section, I'm concerned about "This feature is incomplete ... things don't get properly reset yet.". I'll hold off further comment on that until I hear about the "released, finished being worked on" version that I asked about above.

I have a number of Perls installed on my machine: an ActivePerl and a Strawberry Perl already mentioned in the OP; I have Git Bash which installed its own Perl; Cygwin which also has its own Perl; and Perlbrew Perls. Are any of these affected by berrybrew?

[stevieb]

"Is there a "released, finished being worked on" version?"

Of course! ...here. The version I referred you to is stable and is deemed for release after some doc updates I didn't get done earlier this year.

"I see "... the list of Strawberry Perls available ..." mentioned in the opening remarks, in the available and fetch commands, and in the "Update Perls Available" section. I'm unclear as to what this actually refers. Are all versions on "Strawberry Perl Releases" available? Does "we'll update the local perls.json file" refer to something that berrybrew does dynamically, or an indication of something that will be made available in some later release?"

That refers to newer releases as Strawberry publishes them. 5.34 for example would be added to what berrybrew deems as available as soon as Strawberry builds, releases and adds it to the release list. This isn't added to berrybrew's internal list automatically. I never assume a user has Internet access, so when a new release of Perl is cut, Strawberry follows shortly thereafter, which is when berrybrew fetch is used.

"In the "Configure Root Directory" section, I'm concerned about "This feature is incomplete ... things don't get properly reset yet.". I'll hold off further comment on that until I hear about the "released, finished being worked on" version that I asked about above."

That section refers to people who want to move their Perl installation directory to somewhere that wasn't used when berrybrew was initially set up. This isn't used often at all. I'm going to move that section to a different document. Most users will never need to do this.

"I have a number of Perls installed on my machine: an ActivePerl and a Strawberry Perl already mentioned in the OP; I have Git Bash which installed its own Perl; Cygwin which also has its own Perl; and Perlbrew Perls. Are any of these affected by berrybrew?"

Nope, not at all. In fact, you can add them as a berrybrew managed perl by using the berrybrew virtual command if desired though. All that means is that you can switch back and forth to them as easily as the other berrybrew perls. Nothing is done to the file system at all. It's all done with PATH manipulation. If berrybrew is disabled or removed, everything goes back to normal.

[siberia-man]

I don't tell that my way is the most right and reliable, but it works and covers all my requirements. I have installed three portable versions:

C:\somewhere\on\my\pc\strawberry-perl-5.8.8.3
C:\somewhere\on\my\pc\strawberry-perl-5.16.2.1-32bit
C:\somewhere\on\my\pc\strawberry-perl-5.30.0.1-32bit

I have the soft link C:\somewhere\on\my\pc\Perl pointing on one of these directories. It is created with mklink /d or mklink /j and declared in %PATH% variable. So every time I have full access to one of the Perl instances. If I need to switch to another instance (version), I remove the previous link and create another one pointing to another instance.

[kcott]

G'day siberia-man,

Thanks for your response.

I don't envisage needing to do a lot of swapping between versions; in fact, it may not be necessary at all. However, if my use case changes, changing a symlink would be less work than changing the PATH environment variable.

It would require some initial setup. Unlike you, with three portable SP versions, I currently have: a portable SP version, a non-portable SP version, and an ActivePerl version. I'd probably need to set up some *.bat files for this, but that would be a one-off task.

Thanks for your suggestion. I'll keep it in mind.