Do we want to keep recommending the "msi" installation ahead of all other options ? #49
Comments
|
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 :/ |
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.
So as described, create one :-). I install there, and it works fine. |
|
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 Another option is to point users to tools like berrybrew but that's another layer of work for non-devs. |
|
I should move https://github.com/genio/psperl to this github organization |
|
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 |
|
Hi @there, sorry for my little involvement. Just wanted to say I'm using |
|
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. |
|
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. |
|
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. |
IMO, that's all that should ever have been needed. Anyway, that ship has now not only sailed, but has also been well and truly sunk ;-) Cheers, |
|
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. |
|
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:
|
|
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. |
|
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. |
|
I wondered about that also, but I'm pretty sure Berrybrew uses the portable versions. |
Following discussion in StrawberryPerl/Perl-Dist-Strawberry#49 Main page was updated in a previous commit.
Following discussion in StrawberryPerl/Perl-Dist-Strawberry#49 Main page was updated in a previous commit.
|
The website has now been updated. The MSI installers are now referred to as "system installers" instead of "recommended". |
This hasn't been a problem for CPython. You can install packages into the Program Files site as admin (eg |
|
On Fri, Aug 9, 2024 at 4:35 AM Alex ***@***.***> wrote:
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.
This hasn't been a problem for CPython. You can install packages into the
Program Files site as admin (eg C:\Program
Files\Python312\Lib\site-packages), or into your user folder (eg
%APPDATA%\Python\Python312\site-packages). Just do the same.
If you want to install SP into Program Files, why not just install the
portable version into that location ?
Why do you need to be spoon-fed an msi, when the portable version provides
what you are already seeking ?
I just installed (the portable) SP-5.40.0.1-PDL zip package into C:\Program
Files by running as Admin - without any problems at all.
Shawn's comment about "the broader issue" (which you've quoted) is that,
having installed SP into Program Files, there's a hoop for users to jump
through if they want to install a new module into that build of perl.
That hoop exists, irrespective of whether perl was installed via an msi, or
from a zip file.
With my own SP installation in Program Files, but running as user, I double
clicked on the portableshell.bat and, in the shell that opened up I ran:
####################################
cpan -i Math::Ryu
....
Checksum for
C:\Users\Owner\.cpan\sources\authors\id\S\SI\SISYPHUS\Math-Ryu-1.04.tar.gz
ok
.....
All tests successful.
Files=6, Tests=8277, 2 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
Result: PASS
SISYPHUS/Math-Ryu-1.04.tar.gz
gmake test -- OK
Running make install for SISYPHUS/Math-Ryu-1.04.tar.gz
"C:\Program Files\sp_expt\perl\bin\perl.exe" -MExtUtils::Command::MM -e
cp_nonempty -- Ryu.bs blib\arch\auto\Math\Ryu\Ryu.bs 644
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ERROR: Can't create 'C:\Program Files\sp_expt\perl\site\lib\Math'
mkdir C:\Program Files\sp_expt\perl\site\lib\Math: Permission denied;
Access is denied at C:/Program Files/sp_expt/perl/lib/ExtUtils/Install.pm
line 470.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
at -e line 1.
Files found in blib\arch: installing files in blib\lib into architecture
dependent library tree
gmake: *** [makefile:822: pure_site_install] Error 13
SISYPHUS/Math-Ryu-1.04.tar.gz
gmake install -- NOT OK
#####################################
So the user needs to know how to tell the cpan installation procedure to
install Math::Ryu into some location to which the user has write access.
(Having done that, the user also needs to know how to make this newly
installed Math::Ryu visible to perl.)
Or, maybe the person who installed perl into Program Files should sort out
that issue for the user ?
Or maybe (and I worry this is something you will expect), the SP developers
should fix that, too ?
How do they avoid that issue with CPython ?
|
|
Teaching the various cpan installers to use a local::lib style installation would be a fairly large undertaking, and is not under our control. It might be possible to adapt the MSI system to use Portable.pm, or a variant, to redirect installation to a user's temp dir by default. This is how R works. Any help would be appreciated. This is also probably best discussed under a new issue. Edit: #43 covers this |
Hi,
The Strawberry Perl home page (https://strawberryperl.com/) states that the "msi" version is the "Recommended version".
Do we really want to persist with that recommendation ?
Personally, it's the last version I would want to install ... and if it was actually the only available version then I probably wouldn't install it.
I have a large number of Strawberry Perl installations and they're all "portable" .... thankfully, not one "msi" to be found.
However, I'm not sure that I'm the typical Strawberry Perl user, so I'll leave it as a question for now - and happily close this Issue when I receive an unequivocal answer.
Cheers,
Rob
The text was updated successfully, but these errors were encountered: