I'd like to install a Perl module (in this case, FindBin), but since it is included in the Perl 5.10.1 distribution, cpan wants to install Perl 5.10 for me. Is there a way of installing just the module via cpan?
The only option that I can see is installing directly from source, which seems a bit crude as there is no separate package (for example, Makefile.PL, etc.), just the bare .pm file.
Since this is a small module that only has the one file, it's doable in this case, but what if I wanted to install a much larger package?
EDIT: This is somewhat aside from the original question, but speaks to the general issue of modules being packaged up with Perl distributions: I discovered that the "standalone" FindBin (version 1.49) had a syntactic error, so I retrieved version 1.50 out of the Perl 5.10.1 distribution... However since the module is now listed on CPAN as part of Perl 5.10, I am unable to find the CHANGES file describing what was changed/fixed in this delta. Is it reasonable that I should have to go into the developer repository to pull out this information?)
EDIT 2. Okay, here's a better example. On Perl 5.8.8 I have version 1.04 of Carp. However, I see that Perl 5.10.1 comes packaged with version 1.11. Is there a way of getting CPAN to install the latest version of Carp for me without dragging in all of Perl 5.10.1? I can't even find a link to the Carp module on CPAN except to the perl 5.10.1 installation.
> corelist FindBin
FindBin was first released with perl 5.00307
Which version of Perl do you use that does not include FindBin? If you use at least Perl 5.6.0 (all versions before are considered deprecated), you have no need to install FindBin. If you have anything older, I suggest an upgrade to 5.6.2/5.8.9/5.10.1.
Kurila is not a "standalone" FindBin, it's a dialect of Perl. FindBin is not a dual life and is released only bundled with Perl. You can consider releasing FindBin to CPAN as standalone distribution - it is easy if you used ExtUtils::MakeMaker in past.
Latest useful change of FindBin was on 2007-04-28, related to VMS. Latest useful non-VMS change was on 2006-10-25.
Things you can try include
Dropping FindBin.pm into the same directory as your executable and using use FindBin
Dropping FindBin.pm into your Perl library directory
Using the source code of the module in your script
Related
I have a clean install of perl 5.26.3, and I am trying to install Dancer2.
Dancer2 depends on App::Cmd::Setup, which depends on Getopt::Long::Descriptive, which depends on Params::Validate, which depends on Devel::Peek.
Looking at Devel::Peek on MetaCPAN, it is part of the perl 5.30.2 distribution, and I can not find the Devel::Peek package by itself. The "Jump to version" list on the Devel::Peek page lists previous version of perl, not of Devel::Peek.
Installing Dancer2 on perl 5.26.3 apparently has a hard, transitive dependency of installing perl 5.30.2, but I do not have the authority -- nor any desire -- to update the perl installation.
Is there a version of Devel::Peek available by itself?
Thank you.
Edit
It looks like I have a broken perl installation. I have no Data/Peek.pm anywhere on the filesystem. When I try to use Devel::Peek, I am told Can't locate Devel/Peek.pm in #INC.
I'll install from scratch and start over.
You should be able to fix it with the installation of
yum perl-Devel-Peek
For alpine, be sure to do apk add perl-dev to add additional modules needed to build some packages.
No. It's only available as part of Perl. It's has been part of Perl since 5.6 in 2000.
As such, if you don't have Devel::Peek, you have a broken or partial Perl installation. But this is actually quite common, since many package managers break down Perl into different packages. For example, RHEL split off Devel::Peek into the perl-Devel-Peek package. So if we're talking about a Perl managed by a package manager, check the package manager for the missing bits.
For example I believe that the Encode module is considered a core module and shipped with every copy of Perl. It has its own page on Perldoc:
https://perldoc.perl.org/Encode.html
...but it is also available on CPAN:
http://search.cpan.org/~dankogai/Encode-2.92/Encode.pm
From skimming the two documents, it seems that they contain the same text. So why put it in both places? Is it just so that CPAN can be used to lookup documentation on "any Perl module"?
Such modules are said to be "dual-life" modules.
So users can upgrade the module without upgrading perl itself.
So developers can release fixes and updates to the module on a different schedule (e.g. more often) than perl itself.
Or maybe the module started on CPAN, and it was later added to the perl distro (e.g. because a module in the tool chain requires it).
Or maybe the module is in the process of being removed from the Perl distro.
Also making a core library available at CPAN allows to easily upgrade from the version shipped with Perl to get the latest improvements and bug fixes.
For example, Encode versions shipped with some versions of perl:
Perl Encode
v5.22.4 2.72_01
v5.24.2 2.80_01
v5.26.1 2.88
(retrieved with corelist -a Encode). Any of these can be readily updated to the latest Encode 2.92.
I'm running Ubuntu 14. I tried installing Tk module via cpan. It appears to have installed correctly, however when I tried to use Tk; in my script it still says its unavailable. Is there anything I can do, perhaps add it to #INC somehow? thanks!
Ahdee
It would generally be recommended to install perl modules from the packaging system. For example, in Debian/Ubuntu, Tk would be "perl-tk". Also, since the Tk module includes Tk inside of it, it can't take advantage of newer versions until it is updated to include them. You might look instead at something like Tkx which is libtkx-perl in Debian/Ubuntu. The upside is it uses the system Tk libraries for newer versions; the downside is you have to be more familiar with Tcl as it is a simple binding.
we are using perlbrew for maintaining the various version of perl.
Along , now we are facing challenges as we need to update the scripts to the latest CPAN module. But we want still some the script to keep make use of old perl module till the compatibility issue is resolved.
Is there any away to install the lastest version of module with impacting the older version
perlbrew keeps each version separate, include its CPAN modules. If you run:
perl -E'say for #INC'
you will see the Perl version in the paths. If you switch the Perl, you will see different paths for #INC.
You can still use PERL5LIB with perlbrew-installed perl. But since you're already using perlbrew, why not just install a second build of that version of Perl for use with your newer scripts? Upgrading modules for one perl install won't affect others.
In some environments, Carton maybe the tool you are looking for. It requires a cpanfile where the dependencies are specified, so each script should be handled as an independent application in order to isolate each of them
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).