http://qs1969.pair.com?node_id=11145723

Pursuant to Re^3: Can't locate Convert/BER.pm , here is a suggested version for "A guide to installing modules for Win32 (2022 Edition)"

After any suggested updates (I don't pretend to be an expert, so feel free to correct and nitpick), would this go better as a reply to holli's original A guide to installing modules for Win32, or as a new top-level post in the Tutorials section?

I included the case-sensitivity section because that was an issue in the recent thread Can't locate Convert/BER.pm, even though I'm not sure how general-use that note really is, or whether it really belongs in this tutorial.


Updates: Here is a history of the edits made as a result of suggestions.

  1. Fix cpan arguments (per brian_d_foy's reply)
  2. Add perl Makefile.PL to the "standard recipe" (per syphilis's reply)
  3. Switch to a table, to avoid & (avoiding single & per many recommendations)
  4. Fix formatting syntax (per Discipulus's reply)
  5. Add a note about alternative build recipes (to cover Build.PL and possibly others)
  6. Add a note about incompatible modules
  7. s/skill/system/ in the last paragraph (per hippo's comment

A guide to installing modules for Win32 (2022 Edition)

Nearly two decades later, holli's excellent A guide to installing modules for Win32 could use some updated information.

ActiveState phased out using PPM in 2021 (¹), so starting with ActivePerl 5.28, PPM is no longer included.

And since 2008 (²), there's been an alternative distribution, Strawberry Perl, which comes with it's own gcc/g++ compiler and build environment. Modern Strawberry Perl versions not require using PPM for installation either (though it still ships with a PPM client, if you can find PPM repositories to use it with), so the original Win32 Guide's PPM instructions are not as useful as they once were.

ActiveState's ActivePerl

The modern method of "installing" modules on ActivePerl, as announced in The ActiveState Platform and Perl 5.32, is to make a binary build with the State Tool, where you tell it all the modules you need, and it will provide a binary build with all of those modules (and their dependencies) already installed.

Strawberry Perl

One of the benefits of Strawberry Perl is that they include a working gcc/g++ compiler and build environment, complete with a variant of make (dmake for older versions, gmake for newer versions; see perl -V:make to find out which your copy of Strawberry Perl uses) that means you can easily build and install modules similarly to how it's done on Linux and other OS:

The default CPAN.pm client comes with Strawberry Perl, so installing Some::Module as easy as cpan Some::Module. Strawberry Perl also comes pre-installed with cpanm, an alternative CPAN client that handles dependencies, allowing installation with cpanm Some::Module. You can install cpanplus or other of the advanced CPAN clients on Strawberry Perl as well.

Finally, if you are a traditionalist and want to manually build using the traditional recipe, you can look at the output of perl -V:make and then pick the appropriate variant of the recipe:

traditionaldmakegmake
perl Makefile.PL make make test make install
perl Makefile.PL dmake dmake test dmake install
perl Makefile.PL gmake gmake test gmake install

Some modules may specify their own recipe for building and installing. If so, then try following their directions; the Strawberry build environment is pretty good. But if they specify a different recipe, it doesn't work, and the CPAN-client options don't work, you should file a bug report with the author, because any distributed module should be installable using cpan, cpanm, cpanplus and the like.

For any of these installation techniques: If you have an installed copy of Strawberry Perl, your path should point to the Perl and C binaries already; if you have a portable copy of Strawberry Perl, you may need to run portableshell.bat to get the environment set up correctly.

Other Alternatives

If you have built your own Perl, or for Windows Subsystem for Linux, or cygwin, or other Windows tools that provide bash or bash-like environments, you should still be able to follow the instructions in the original A Guide to Installing Modules for installing, or use cpanm or cpanplus or other clients not mentioned in the original guide.

Win32 Caveat: Module Case Sensitivity

File names on Windows are not case-sensitive, so some Windows users are used to typing PATHS IN ALL CAPS. Do not type module names in all caps, even when using a CPAN client from the Windows command line (cmd.exe or powershell), as Perl and the CPAN tools will not treat SOME::MODULE and Some::Module the same, even if they resolve to the same ...\Some\Module.pm file.

Windows Incompatibility

Please note that some modules have been created in such a way that they are incompatible with the Windows operating system. This guide cannot help you install and use a module that is not compatible with your OS. (You can check the CPAN Testers reports linked from the metacpan.org page for each module: if it doesn't show any passing results on the mswin32 platform, you may have difficulty installing the module.)

Replies are listed 'Best First'.
Re: RFC: A guide to installing modules for Win32 (2022 Edition)
by brian_d_foy (Abbot) on Jul 26, 2022 at 01:48 UTC
    Note that the -i switch to cpan is implied if there are no other switches, so it's even easier as cpan Some::Module.
Re: RFC: A guide to installing modules for Win32 (2022 Edition)
by syphilis (Archbishop) on Jul 26, 2022 at 02:22 UTC
    LGTM - though a couple of minor nitpicks.
    One thing I might change is to replace the first occurrence of "make" in make & make test & make install with "perl Makefile.PL". (And similar wrt the "gmake" and "dmake" variants of the same expression.)
    And perhaps those occurrences of & should be changed to &&. I'm finding (in cmd.exe shell) that if I run perl Makefile.PL & gmake test & gmake install then the module gets installed even if gmake test failed.

    Thank you for creating that tutorial !!

    Cheers,
    Rob
      For the &, I had originally intentionally picked the ;-equivalent single-&. But after the comments that I shouldn't, I decided to put it into a table, so that it has the traditional presentation of the recipe, which is a four-line sequence rather than a single command.
Re: RFC: A guide to installing modules for Win32 (2022 Edition)
by Discipulus (Canon) on Jul 26, 2022 at 07:37 UTC
    Hello pryrt and ++ my friend for this updated tutorial!

    just some minor things from my part.. In the Strawberry Perl section I'd invert the paragraph position: first the plain simple way using cpan client, then the make method that I consider less frequently used and more hackish. Users used to windows rarely understand making things and also installing something in the command line is considered a dangerous journey.

    Also some cpan frequently used interactive commands, in a pseudo session, as example can be a benefit for win32 users. For example:

    cpan> # to install Some::Module just type: cpan> install Some::Module # to see if there are updates for a module use 'r' cpan> r DBI ... Package namespace installed latest in CPAN file DBI 1.637 1.643 TIMB/DBI-1.643.tar.gz # to upgrade some module to the latest version use 'upgrade' cpan> upgrade DBI

    I dont know if it is worth to mention that Strawberry puts its own mirror as first one in the cpan configuration:

    cpan> o conf urllist urllist 0 [http://cpan.strawberryperl.com/] 1 [http://www.cpan.org/]

    ..and for it I hit: LWP failed with code[500] message[Can't connect to cpan.strawberryperl.com:443]

    Minor editing nitpick: it seems you are using the wikisyntax for the monastery: if so after the single quote you cannot have any char: 'cpan -i Some::Module'. does not work, you need good old tags if you want the dot: <c>cpan -i Some::Module.</c>

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
      Part of me wanted to keep the order with the "traditional recipe" first, because that's the order presented in the original A Guide to Installing Modules. But since I agree that using cpan or alternative clients is preferred, I followed your advice and changed the order.

      For the cpan configuration and usage suggestions: are those really Win32-useful enough that they belong here? Or are they just generically useful? Do others think that this tutorial should include that suggested extra detail about the CPAN shell? or even more than that? What about extra hints for the other clients?

      Wiki syntax: I often forget to put that space after the end-single-quote. I had actually noticed that on another instance, and thought I had converted all of my wiki syntax to plain Perl Monks Approved HTML tags, but I missed those. Thanks

Re: RFC: A guide to installing modules for Win32 (2022 Edition)
by soonix (Canon) on Jul 26, 2022 at 07:06 UTC
Re: RFC: A guide to installing modules for Win32 (2022 Edition) -- cpanm
by Discipulus (Canon) on Jul 26, 2022 at 10:05 UTC
    Hello again pryrt,

    I forgot to mention my opinion about cpanm already presented in Re: Should cpanminus be part of the standard Perl release? -- MSWin32: something is changed and now is able to test succesfully Text::Xslate but other issue are still there and so I do not suggest it for win32 users. Mainly do not handling path correctly in 2022 is... strange :)

    ---------------------------------------------- Welcome to Strawberry Perl Portable Edition! Perl version : 5.32.0 / MSWin32-x64-multi-thread C:> cpanm --version cpanm (App::cpanminus) version 1.7044 (C:\EX_D\ulisseDUE\perl5.32.64bi +t\perl\bin/cpanm) <--------- O_O \ \ \ /? C:> cpanm --self-upgrade + Can't find Unicode property definition "e" in regex; marked by <-- HER +E in m/^C:\EX_D\ulisseDUE\pe <-- HERE rl5.32.64bit\perl\site\bin/ at +C:\EX_D\ulisseDUE\perl5.32.64bit\perl\bin/cpanm line 32. + ^---- O_O ?!?! C:> cpanm --test-only Text::Xslate ... Successfully tested Text-Xslate-v3.5.9

    Unfortunately the will to ignore win32 as a big market share seems to persist in the habits of some, even genial, dev which anyway deserve my deep respect.

    If in you I'd remove completely any mention to cpanm for win32 users

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

      cpanm works for me on Windows, but it's weird that your Perl / cpanm mixes the path separators. The rest is an unfortunate consequence of that.

      I'll look at whether cpanm --self-upgrade tries stuff that normal operation does not.

      If in you I'd remove completely any mention to cpanm for win32 users

      Odd, I rarely have troubles when using cpanm on win32 (in fact, it's the only CPAN client I use on Windows). But it is true that I never bother to cpanm --self-upgrade : I cannot think of a time since 5.010 where I really thought "I need to upgrade my cpanm client". Maybe I'm the exception in that regard.

      And I see the mixed matchsticks, too, but it hasn't seemed to bother cpanm for me:

      C:\> where cpanm c:\usr\local\apps\berrybrew\perls\system\perl\bin\cpanm c:\usr\local\apps\berrybrew\perls\system\perl\bin\cpanm.bat C:\> cpanm --version cpanm (App::cpanminus) version 1.7044 (c:\usr\local\apps\berrybrew\per +ls\system\perl\bin/cpanm) perl version 5.030000 (c:\usr\local\apps\berrybrew\perls\system\perl\b +in\perl.exe) ... C:\> c:\usr\local\apps\berrybrew\perls\system\perl\bin/cpanm --version cpanm (App::cpanminus) version 1.7044 (c:\usr\local\apps\berrybrew\per +ls\system\perl\bin/cpanm) perl version 5.030000 (c:\usr\local\apps\berrybrew\perls\system\perl\b +in\perl.exe) ...
      (in fact, as shown, it doesn't bother cmd.exe, either)

      but other issue are still there and so I do not suggest it for win32 users. Mainly do not handling path correctly in 2022 is... strange :)

      been using it since it came out on win32

      its not perfect, but its more perfect than cpan/cpanp . and for longer too (weird but true)

      heh site:perlmonks.org fix old bugs don't just complain

Re: RFC: A guide to installing modules for Win32 (2022 Edition)
by hippo (Bishop) on Jul 28, 2022 at 15:18 UTC

    The last paragraph currently starts with

    Please note that some modules have been created in such a way that they are incompatible with the Windows operating skill.

    It doesn't read quite right to me - are the final 2 words correct?


    🦛

      are the final 2 words correct

      "One out of two ain't bad?" ;-)

      s/skill/system

Re: RFC: A guide to installing modules for Win32 (2022 Edition)
by pryrt (Abbot) on Jul 26, 2022 at 14:42 UTC
    Do others think I should add the Module::Build recipe as well?
    perl Build.PL Build Build test Build install

      I hope people will eventually drop that and go back to Makefile.PL, but that might be my biassed vision. But if the Build.PL example is added, it might be a small step to also include a dzil example. Down this road lies madness.


      Enjoy, Have FUN! H.Merijn
        it might be a small step to also include a dzil example

        I'm not aware of any dist/nodule which requires dzil just for installation, thankfully.


        🦛

      Do others think I should add the Module::Build recipe as well?

      Thankfully, many modules that were originally built to use Module::Build, also provide a Makefile.PL. (One of those modules is Module::Build itself.)
      I suppose there are still some modules that don't provide a Makefile.PL.

      I guess the responsible thing to do would be to specify that the Module::Build mantra be used in those rare instances that a Makefile.PL is not provided.

      I, however, would be tempted to provide a far more irresponsible (tongue-in-cheek) handling:

      "If a Makefile.PL has not been provided then the module is not worth installing";
      or (slightly less offensive):
      "If a Makefile.PL has not been provided, file a bug report".

      The former is, of course, not necessarily true - and the latter is probably little other than arrogant.
      By way of explanation, I have always found Module::Build to be intensely annoying, and I try to avoid making any statements that might infer that the use (or even the mere existence) of that build process is valid or useful.

      Cheers,
      Rob
Re: RFC: A guide to installing modules for Win32 (2022 Edition)
by pryrt (Abbot) on Jul 28, 2022 at 14:53 UTC
    Based on the feedback, I am thinking it's in pretty good shape at this point. Should I post it as a top-level in Tutorials, or as a reply to the original?

      My inclination would be to post it as a new top-level, with a brief comment on the original to point to it.

Re: RFC: A guide to installing modules for Win32 (2022 Edition)
by pryrt (Abbot) on Jul 31, 2022 at 22:06 UTC