I'm trying to install PAR from cpanm like so: cpanm App::Packer::PAR, but it's giving me this error:
skipping R/RJ/RJBS/perl-5.22.0.tar.bz2
! Installing the dependencies failed: Module ExtUtils::Embed is not installed
! Bailing out the installation for PAR-Packer-1.026.
Even though cpanm is supposed to automatically install dependencies, I tried installing it manually: cpanm ExtUtils::Embed, but only got the same error: skipping R/RJ/RJBS/perl-5.22.0.tar.bz2
Any ideas as to why this is failing and how I can make it work?
ExtUtils::Embed is a dual-lifed module, meaning it's distributed as part of the perl distribution as well as in a second distribution.
cpanm is trying to install ExtUtils::Embed by installing the perl distribution instead of the ExtUtils-Embed distribution. Why? I'm not sure. Maybe because it's newer (1.32 instead of 1.2505).
cpanm is wisely unwilling to upgrade perl itself.
Now, the latest App::Packer::PAR's META doesn't specify a minimum version of ExtUtils::Embed, so the version in the ExtUtils-Embed distribution could very well be good enough. The following command will achieve this:
cpanm D/DO/DOUGM/ExtUtils-Embed-1.14.tar.gz
HOWEVER, as I mentioned earlier, ExtUtils::Embed comes with Perl. It has done so for over 15 years (since before Perl 5.4). It makes no sense that you have to install it.
You appear to be using a system whose provider decided to cause headaches by breaking the perl distribution into multiple packages. You should use your system's package manager (apt-get, yum or whatever) to install the missing portions of perl rather than using cpanm.
Related
While loading necessities into my crouton, apt-get recommended that I install libtemplate-perl. This seemed a jolly idea, and I obeyed.
Reading this answer, I see a fellow traveler install Plack and Starman via CPAN, but then use apt-get to install Dancer.
Minutes before reading said answer, I had installed Dancer via CPAN. And it had worked. It had worked real good!
What happens differently when I install a CPAN package via a non-CPAN package manager? Are there pitfalls I need to be wary of because my libtemplate-perl came from apt-get, or my Dancer came from CPAN?
On Debian or Debian based distros like Ubuntu, CPAN (/usr/bin/cpan utility) installs modules into /usr/local/lib/ by default. And Debian packages keep their files in /usr/share/perl5/ and /usr/lib/perl5/.
It's a better way to choose dh-make-perl tool to package any CPAN distribution not available in your apt repositories, to avoid making mess (serious risk of conflict between apt and CPAN):
dh-make-perl --build --cpan Some::Module
dpkg -i some-module*.deb
Also check out about local::lib and perlbrew.
A lot of tutorials, Stack Overflow answers, walk throughs, etc. will not want to assume that you know how to use /usr/bin/cpan and will instead suggest that you use your system's package manager, which you are more likely to be familiar with.
This is especially true if you are using a tool written in a particular language, but you don't know that language. For example many people wouldn't care whether crouton is written in Perl, Python or Lisp, they just want a tool they can use. Your average Debian or Ubuntu user is more likely to be familiar with apt-get than with cpan.
If you are looking to program in Perl I recommend installing things by cpan, using perlbrew and/or local::lib. If you are just looking to install a tool you can use, I would recommend using apt-get.
Additionally apt-get has the advantage that non-Perl dependencies will be installed automatically. For example the CPAN module XML::LibXML requires that the libxml2 headers are available on the system; the CPAN distribution has no way of stating that as a dependency, and will simply fail on install if it can find the headers to link against. The Debian package can actually specify that libxml2 is a dependency, and will install the dependency automatically for you.
Despite that if you are looking to use XML::LibXML as a Perl programmer, I would recommend installing it with cpan and installing the libxml2 package via apt-get. Having all your Perl modules installed in the same place - again, via perlbrew or local::lib - will help you keep your sanity in the future. CPAN is preferable to apt-get in this case because not all distributions have been packaged for Debian, and so you get a lot more options if you use CPAN directly.
In summary: TIMTOWTDI ;-)
Another difference to mention that I don't see in other answers, is that if you use CPAN to install a module then the module version you get will be set, until you decide to upgrade that module. Whereas, if you use apt and a later version appears in Debian at some point in the future, then apt-get upgrade will update it.
Maybe you want that, maybe you don't. It's neither necessarily an advantage, nor a disadvantage. Simply a difference to be noted.
The good things about apt-get are
that you can uninstall the packages afterwards should you need to
if you are maintaining any number of servers it is quicker to use apt-get as there is no building required
there are definite versions of packages which are tested for compatibility
The downsides are
not necessarily the latest version of packages
not all packages are available
apt-get installs are generally easier and better than cpan because of dependencies alone.
If you are so lucky as to need SOAP::Lite, for example, it is many dozens of dependencies, and a one-line "apt-get install libsoap-lite-perl".
It is sometimes not clear how Perl CPAN names map to their repository package names, but "apt-cache search " is your friend.
Another approach, that can be used for any distro in HOME install as simple user:
Pros
avoid conflicts
up to date version of perl and modules
when you reinstall, you keep your home/perl as-si
you can upgrade all installed modules with $ cpan -r
Cons
you need to upgrade Perl manually
How to
Edit ~/.bashrc or such, and add:
export PERL5LIB=~/localperl/lib/
export PATH=~/localperl/bin:$PATH
Then
source ~/.bashrc
Install latest Perl5 from sources: https://www.cpan.org/src/README.html
Now, you have an isolate Perl installation in your home.
Enjoy the power to install any libs via:
$ cpan -i Whatever::Module
I am installing this module in Ubuntu:
http://metacpan.org/pod/CatalystX::DynamicComponent::ModelsFromConfig
with bash command:
sudo cpan CatalystX::DynamicComponent::ModelsFromConfig
However I always get this message:
Warning: Cannot install CatalystX::DynamicComponent::ModelsFromConfig, don't know what it is.
Is this means this module is not a standard module?
There is no stable, indexed release of that module, only a developer preview release. With a recent version of cpanminus you could do
cpanm --dev CatalystX::DynamicComponent::ModelsFromConfig
with regular CPAN.pm you should be able to do
cpan BOBTFISH/CatalystX-DynamicComponent-0.000000_01.tar.gz
That or come onto irc.perl.org #catalyst and talk to t0m about the module and whether it makes sense for you to be using it — it seems to be abandoned since 2009. I think the sensible replacement is CatalystX::ComponentsFromConfig.
I'm trying to install the YAML::Syck module (I'm actually trying to install Date::Manip, this is just a dependency), but it fails with the following message:
This module requires a C compiler at Makefile.PL line 38.
This happens whether I try to install using CPAN or if I try to download the packages and install manually.
I have gcc installed and on my PATH, I can access it from the same CYGWIN shell window that I'm trying to use to install YAML::Syck.
When looking for a C compiler, ExtUtils::MakeMaker and Module::Build don't necessarily look for gcc in your PATH, but query your perl's configuration for the C compiler it has been built with and expects it to be available for building Perl extensions as well.
On my system, it will look for cc in PATH, as per
$ perl -MConfig -E'say $Config{cc}'
cc
I've had trouble in the past getting everything to "just work" with cygwin, when it comes to compiling modules. You might want to take a look at Strawberry Perl, which is a Windows Perl distribution that comes bundled with all of the components needed for compilation of XS modules. I haven't personally tried to install YAML::Syck with it, but I have installed many other XS modules without incident.
Once it is installed and in your path (usually automatically), you should be able to run cpan from the Windows command prompt to install the module.
Maintainer speaking
The better forum to ask is the cygwin mailinglist. There you will find the same questions being asked again and again, we can point to the messages, and the
maintainers are present.
The quality of the answers will be much better.
The official latest perl announcement was http://sourceware.org/ml/cygwin-announce/2012-07/msg00011.html
perl used to bundle most useful modules for CPAN and Testing with the core perl.
With the latest 5.14 package the useful modules were moved to the seperate package perl_vendor.
The dependencies to be able to compile modules by your own via cpan are not included.
You'll need make and gcc-4 at least.
See /usr/share/doc/Cygwin/perl.README for the package specific README.
YAML::Syck is considered broken and unmaintained (*_why* left), please try to use a better YAML package, like YAML or YAML::XS, written by the inventor and author of YAML itself (ingy).
Date::Manip does not require YAML::Syck. cpan does like to have a YAML modules, but prefers YAML::XS.
You'll find out that you'll be able to install much more packages with cygwin perl than with strawberry perl (=mingw).
I tried:
cpan> i /xls2csv/
No objects found of any type for argument /xls2csv/
cpan> install xls2csv
Warning: Cannot install xls2csv, don't know what it is.
Try the command
i /xls2csv/
to find objects with matching identifiers.
I haven't had any problems installing registered modules, e.g.
cpan> install DateTime
It is just the xls2csv that is providing problems.
Thank you for any insights provided.
P.S. Constrained To Windows with ActivePerl 5.10 (I think) Also I have the xls2csv-1.06.tar.gz file downloaded and tried
cpan> install C:/...path to file locally/xls2csv-1.06.tar.gz
That did not seem to work, and I must install locally.
The indexes used by CPAN.pm are all module-oriented, so they don't see distributions that contain no modules. (xls2csv has only a script.) You can still install them by giving the full path (under authors/id) of the distribution, just as you would to install older or development versions of a distribution:
cpan> install K/KE/KEN/xls2csv-1.06.tar.gz
If you are using my cpan(1) command, you can also install whatever is in the current working directory by telling it to install ".".
% cpan .
That should trigger the normal CPAN.pm process for handling dependencies and so on. You should be able to do that in the CPAN.pm shell too.
If you want to fetch the file from a CPAN mirror, you can do it as ysth suggested. You give it the path under authors/id in the repository and CPAN.pm will find it for you. You're skipping the step where it looks in the PAUSE index because you've already given it the path to download.
It's a 5 year old script with few tests (7) none on a Mac, and one bug report (a year old). It appears to not have been updated since it was written so use this script with realistic expectations. In other words, don't be surprised if you can't get it to work.
I upgraded to Ubuntu Intrepid Ibex yesterday and suddenly some of the Perl modules that I installed (on the Hardy Heron) have all gone missing!
I get the usual "Can't locate module in #INC" error. Has any of the CPAN repositories changed or something for Intrepid? Google doesn't help at all.
Thanks in advance.
The standard solution is to generate an "autobundle" with CPAN.pm before upgrading Perl. A search for autobundle yields links to a handful of existing SO questions discussing Perl module management and several that look like they should provide more information. The CPAN.pm manual touches on autobundle, but doesn't include much detail.
Since you've already upgraded Perl, one solution for installing your modules would be to generate an autobundle file and use the entries in the generated file as a guide to write a custom autobundle file with entries for your modules (only). The autobundle file format is just POD, so this should be easy to do.
In the future you should probably make it a habit to generate an autobundle before upgrading Perl. This is not a perfect solution, the autobundle will include entries for core modules that will have to be removed before actually building from it, but at least you'll have a snapshot of installed Perl modules so that you can get your Perl install fixed up after an upgrade.
Your Perl installation has changed from version 5.8 to 5.10. Since many of the modules you want are in perl-version-specific directories, you may want to re-install using the CPAN tools (e.g. the cpan command).
But since you're using Ubuntu, please keep in mind that many many CPAN libraries are also distributed through the Ubuntu package manager, and the CPAN packages install into a different place than Ubuntu installs them (this is transparent to the user, since both are in the #INC paths).
I recommend using the Ubuntu packages when they're available, because they will be updated by the package manager (APT) when new ones are released on the central package servers. The name format is slightly different. Here are two ways to install the same package, from different sources:
$ cpan List::MoreUtils # installs latest from CPAN
$ sudo apt-get install liblist-moreutils-perl # installs latest from Ubuntu universe
the advantage of the latter is that it will be updated by sudo apt-get update.
Perl changed on Intrepid.
Before upgrading, you had Perl 5.8, now you have 5.10.
Probably /usr/lib/perl5/5.10.* is used instead of /usr/lib/perl5/5.8.8 since the Perl version has changed