Do we want to keep recommending the "msi" installation ahead of all other options ?

[sisyphus]

Do we want to keep recommending the "msi" installation ahead of all other options ?

[genio]

https://blogs.perl.org/users/chase_whitener/2019/07/windows-and-perl.html is the article I wrote on PSPerl when I first created it. I've now moved it to this organization: https://github.com/StrawberryPerl/psperl

[csjewell]

I'll admit that I originally wrote that back in 2009 when almost nothing within perl liked spaces in the path - I chose to error out even before the installation in order to avoid the complaints.

Maybe now we can see what we can do to eliminate the need for it.

[shawnlaffan]

FWIW, the 5.38.0.1 MSI is being downloaded many more times than the portable versions. This is from a github release page which does not specify a recommended installer.

Current stats are:

• 1150: MSI
• 75: Portable
• 57: Portable PDL

https://tooomm.github.io/github-release-stats/?username=strawberryperl&repository=Perl-Dist-Strawberry

[shawnlaffan]

The website has now been updated. The MSI installers are now referred to as "system installers" instead of "recommended".

[christophvw]

MSI is the best option to deploy this in enterprise environments. Portable is not an option there.

I would like to have a MSI installer which installs Strawberry to %ProgramFiles% but it looks like too many developers cannot handle spaces in paths properly :/

[kenneth-olwing]

MSI is the best option to deploy this in enterprise environments. Portable is not an option there.

I'd totally agree with sisyphus here and argue the opposite.

It is childs play to use something like Innosetup to create your own installable based on a portable package. With the added benefit that you can control where it installs and how it should otherwise be configured in an enterprise setting. Also very handy to be able to make parallell installs of various versions, or even different groupings of modules - I have multiple installers ranging from basic to chock-full of non-standard cpan modules, and can create more if necessary, all based on different base Perl versions etc.

If anything, I would dearly love to get a Perl dist for Linux with the same 'Portable' stuff as on Windows. Haven't really delved into this so I'm not sure how to go about it. But in an automated setting where I can just populate a tree anywhere in a filesystem and run it as a self-contained Perl installation is hugely advantageous.

I would like to have a MSI installer which installs Strawberry to %ProgramFiles% but it looks like too many developers cannot handle spaces in paths properly :/

So as described, create one :-). I install there, and it works fine.

[shawnlaffan]

The portable version is what most devs would want, and is what I've been using for several years (similar to @sisyphus and I assume others). However, the default should target the greatest number of people. Many users will want a perl that "just works" so they can run some code without needing to worry about running the portable shell or updating the paths for their IDE.

I suspect changing the wording on the web site from "preferred" to "standard" (or maybe "system" or something else) will address the original concerns.

As for installing to a path with spaces, if the various cpan modules can be installed in a path with spaces then I see no reason not to. The MSI process currently throws an error if a path with spaces is used, and the checking code pre-dates 2012 (assuming I found the correct file).

Perhaps someone could locate a portable version in a path with spaces and then try installing a range of modules from cpan?

I guess the broader issue with installing to C:\Program Files is that users will likely need to install modules to somewhere else. That introduces complexities for non-devs.

Another option is to point users to tools like berrybrew but that's another layer of work for non-devs.

[genio]

I should move https://github.com/genio/psperl to this github organization

[g-bougard]

Hi @there,

sorry for my little involvement.

Just wanted to say I'm using Perl::Dist::Strawberry to package glpi-agent for windows as MSI in any wanted path and the default is to use C:\Program Files\GLPI-Agent. Of course I had to tune a lot the build process but this is possible.

[mohawk2]

Using the portable edition and putting it in a "place with a space" (and also round-brackets in the path, to catch even more problems) has been my strategy for years. I've submitted quite a few patches to fix issues this highlights.

I wish someone would run a CPAN smoker with such a setup.

[shawnlaffan]

It would be good to update the website given we are close to a 5.36.1 release.

The simplest approach is to change "recommended" to "system installer" on the main page.

Does someone want to open a PR on the website repo? Discussion of the exact wording can be done there.
https://github.com/StrawberryPerl/strawberryperl.com

[sisyphus]

I chose to error out even before the installation in order to avoid the complaints

IMO, that's all that should ever have been needed.
It still enrages me to think of all the time and effort put into accommodating the pathetic desire to have spaces in paths ... all just because some people decided that the other 64 (or however many there are are) allowable characters are, alone, insufficient.

Anyway, that ship has now not only sailed, but has also been well and truly sunk ;-)

Cheers,
Rob

[wchristian]

Re the top question:

Yes, absolutely recommend a system level installer. For anyone seasoned who needs a portable perl it's not a hindrance to have a system perl installed. However for other people starting with the portable one might add struggles.

Any consideration here based on personal experience of an advanced programmer is irrelevant if it is not paired with an assessment of the target audience and impacts thereon.

[shawnlaffan]

Although the rate at which the MSI installs are increasing (1588 MSI downloads about 18 hours later) makes me suspect one or more continuous integration processes is responsible for a chunk of the downloads.

It's not https://github.com/shogo82148/actions-setup-perl as it uses its own GH releases: https://github.com/shogo82148/strawberry-perl-releases/releases/ , and chocolatey is yet to be updated, but there could be any number of self hosted runners.

If someone knows how to get more granularity in the download stats, e.g. geolocation to country or regional level, then that would be useful.

[genio]

I would also assume some of that is the BerryBrew community as they seemed eager to get the releases.json updated to have available on their service.

[shawnlaffan]

I wondered about that also, but I'm pretty sure Berrybrew uses the portable versions.