I think that this is the last straw, and I'm now really completely done with Perl as anymore more than a write-once short-script language.
CPAN and /usr/bin/cpan as installed by native package management apparently do not work out of the box on stock MacOS, on stock Solaris, on stock Illumos, on stock Ubuntu, on stock Debian, on stock Fedora, on stock RHEL, or on stock CentOS.
Perl is now worse than the various implementations of the JVM at assuming that an entire box is going to be turned into a "Perl machine" and that the admin of that machine has any interest in keeping track of all the ways that Perl is special, and in all the ways that Perl wants to make that machine "special".
I mostly gave up on Perl about 3 years ago, and about once a year I go back and give it other try, and each time the experience is worse.
skip to main |
skip to sidebar
Public musings about the technologies and implications of cloud computing, open source software, open standards, and any other stuff that I find interesting.
About Me
Disclosure
The opinions expressed in this blog are mine, and are not necessarily the opinions of any other person or organization. I get paid to have my own opinions, and to exercise my own skills. Nobody pays me to pretend to hold their opinion. I am not a shill.
Sometimes I am given marketing shwag, review copies of books, or get free or pre-release access to services, events, technologies, and goods. I'm not going to bother carefully "disclosing" such.
Sometimes I am privy to private or confidential or embargoed or properly NDAed information. I will not improperly disclose such information, especially not in this blog.
If any of my readers wants to share information with me face to face, off the record, on the background, no notes taken, feel free to drop me a line. I'll buy the beer.
We can't do anything with "doesn't work".
ReplyDeleteThe CPAN shell isn't great out of the box, but I know it's not that broken. Calm down, take a deep breath, crush a pack of Camels and tell us what's wrong.
With Schwern here.
ReplyDeleteWe get that you have found something about CPAN you don't like. We, as a community, obviously do not wish you to experience this negative experience.
Unfortunately, you haven't given us anything we can work with to help this problem go away.
So please, if you have the patience, tell us what you banged into, how it frustrated you, and more importantly, *why* it frustrated you.
Granted, I think we need to work closer with distribution tool-chains to minimise the pain for people to work in a modern Perl development style, and try to better leverage their technology so people like yourself are given the most appropriate knowledge to get started.
But trying to convince downstream to play nicely in ways we ask them to can be a challenge.
In the interim, between now and whenever you respond, I'll suggest a few things that could help, but its largely based on assumptions about what you appear to be doing.
ReplyDeleteThe only way I can envision "CPAN taking over my machine" so to speak, would be if you're running the CPAN client as root, and this is not necessary, or recommended.
On any given distribution/operating system, the recommendation is usually either "exclusively use the libraries and package management tools provided to you by that system, and avoid the CPAN client(s) completely", or "assume that the tool-chain your distribution uses for Perl things as separate from your own tool-chain for Perl things, and maintain them separately".
These days, people seem to be strongly in favour of the latter, because it seems to be easier to use, more cohesive and self-contained, and easier to ship around places. ( It also has the benefit of being separate from your systems Perl, so you're not bound to their release cycle, so you can update whenever you want to, not when they force you to, or when they decide to let you )
To do this, people tend to build their own copy of Perl inside their own user, using PerlBrew ( https://metacpan.org/module/App::perlbrew#INSTALLATION ), giving them a fresh Perl setup seperate from your systems Perl.
Alternatively, you can use local::lib ( https://metacpan.org/module/local::lib#SYNOPSIS ) , which gives you the convenience of using your system Perl, but allows you to have a personalised module tool-chain.
Granted, neither of those 2 modules come "out of the box" with Perl, but your Linux/Unixy distribution doesn't give it to you out of the box either, or show you how to use them even if they were there.
And finally, there is a 3rd tool people have come to love recently, cpanm ( https://metacpan.org/module/App::cpanminus#INSTALLATION ), which tends to be faster and easier to use than the aging 'cpan' client, and comes with a few neat tricks that make life easier ( such as the -l parameter, which does something akin to the aformentioned local::lib setup )
You might also want to check out the Modern Perl book, which is freely available for download, which does cover all of the things I stated above, and will hopefully teach you the most practical aspects of Perl. ( http://www.onyxneon.com/books/modern_perl/index.html )
Hope that helps.
-- Love,
The Perl Community.
What KENTNL said, plus:
ReplyDeletePerlbrew homepage is http://www.perlbrew.pl/, it includes a quick-start guide.
After perlbrew is installed, I install the cpanm CPAN client, its less verbose and more memory efficient than the classical cpan client: perlbrew install-cpanm
And finally I install the latest perl and make it the default:
perlbrew install 5.14.2
perlbrew switch 5.14.2
It might seem strange to recommend not to use the system perl, but over the years, I came to understand one thing: the system perl is usually very out-of-date, and sometimes it has vendor patches that kill the performance (RedHat is a usual offender here).
By installing the latest version in a isolated environment on your account (a quick process, actually, and you can make it even faster with perlbrew install -j 5 5.14.2 on a multi-process machine), you are assuring yourself that you have the latest perl the community released, with the latest improvements to the language and the compiler, and you can install modules out-of-the-box, no hassles.
After this, cpanm MODULE works fine. Modules that don't install usually mean that the test suite didn't pass on your computer. You can either ignore the tests with cpanm -n Module, or you can check the build.log (in ~/.cpanm/build.log) if you want to know what is the problem.
Best regards,
I wonder why the native package management bothers to install /usr/bin/cpan at all. If you are using vendor packages for perl you'd probably want to do so for additional CPAN modules too.
ReplyDelete