in reply to Perl modules in Windows

To add to what DaWolf said, be warned that the module names as used by ppm are not always the same as the module. My recollections is that sometimes (but far from always) they make everything lower case, and they like replace :: with -. So you might have to install net-irc or Net-IRC rather than Net::IRC.

Going forward at some point (perhaps now? I don't have Windows to test it) I believe that it should be possible to use CPANPLUS with code that uses Module::Build so that you can install versions of modules without being at the mercy of ActiveState or some other volunteer to repackage them for you. Not many module authors have switched yet though...

Replies are listed 'Best First'.
Re: Re: Perl modules in Windows
by iburrell (Chaplain) on Nov 05, 2003 at 18:09 UTC
    ActiveState uses the distribution name for the package name instead of the primary module. For most modules, this just involves replacing the colons with a dash. For other it is completely different. For example, Net::LDAP is in the perl-ldap package. PPM can't map module names to distributions like CPAN can. search.cpan.org is a big help to find out what distributions a module is found in if the default doesn't work.

    It is possible to use CPAN (and probably CPANPLUS) or manual install with Windows. ExtUtils::MakeMaker supports and uses nmake on Windows. Binary modules are harder to build because they need the environment used to build Perl. For ActivePerl, this is Visual Studio. Building binaries is just harder on Windows; Module::Build does not help much.

[reply]
      Good information. However I would like to note that if CPANPLUS and Module::Build work as they are supposed to, then pure Perl modules should be installable without having nmake. That won't help if the module uses XS, but it would help with a large fraction of the modules out there.
[reply]
Re: Re: Perl modules in Windows
by DaWolf (Curate) on Nov 05, 2003 at 21:00 UTC
    True, tilly, but at least since ActivePerl 5.6.1 PPM automatically translates the "::" to "-".

    Actually PPM or maybe ActiveState's repository itself has its caveats, such as it's impossible to install MIME::Lite, 'cause it shows up twice there...

    <UPDATE>
    Actually I was wrong here, and tilly was somewhat correct. If ppm finds more than one result for a module you can choose wich one to install by numbers. PPM 3.0 translates '::' to '-' on the install command, but it doesn't for the uninstall command...
    </UPDATE>

    But to people that are used to work with ActiveState's products - I use Komodo, their multi-language editor - knows that they have some strange bugs sometimes (no flame intended here).

    Justo to be sure that nobody misunderstands me, I love Komodo and I think ActivePerl and PPM are great products, but they sure have it's problems.

    Best regards,

    my ($author_nickname, $author_email) = ("DaWolf","erabbott\@terra.com.br") if ($author_name eq "Er Galvão Abbott");
[reply]
      The idea of a PPM repository is somewhat novel, but ActiveState is certainly not responsible for it. ExtUtils::Installed and ExtUtils::MakeMaker are. All ActiveState came up with is an XML format to describe packages, prerequisites (PPD). The ppm distribution (module utility and related files) are very poorly managed and maintained (just look at the source http://downloads.activestate.com/PPM/PPM-3.00.56-src.tar.gz, no tests of any kind).
[reply]

In Section Seekers of Perl Wisdom