(kudra: CPANPLUS) Re: To install a module...
by kudra (Vicar) on Sep 27, 2002 at 10:35 UTC
|
As of 5.10, CPANPLUS will become part of the core (under another,
undetermined name). Although at this
point it is at version 0.036 and the public interface is still subject
to change, most of the fundamental pieces are in place. Now is a
good time to test it out and report any bugs.
One thing that should be noted is that you should not try to install
CPANPLUS via CPAN.pm--the interactive install doesn't seem to be handled
properly.
You can read about CPANPLUS at
sourceforge.
There was also an
article, although it discusses an earlier version so some syntax might
be obsolete. An additional
article
describes the interface to testing.
Some of the main differences between CPANPLUS and CPAN.pm are:
- CPANPLUS is designed to work cross-platform (parts of it are written
in the Windows environment)
- CPANPLUS has a layered interface which seperates the shell from
the programatic interface.
| [reply] |
|
| [reply] |
|
#!/usr/bin/perl
BEGIN {
$ENV{ftp_proxy} = 'current.domain.org';
}
use CPANPLUS;
shell();
This example comes from the FAQ. "Can I use
a local mirror..." might also be appropriate; I'm
not completely sure what you're pointing out.
You can mail the bugs list or the general suggestion
list, cpanplus-bugs and cpanplus-info
respectively, at lists.sourceforget.net to
report bugs or make suggestions. Other contact information
is also found on the
sourceforge pages. | [reply] [d/l] [select] |
|
|
|
I noticed that not enough people are using CPANPLUS, IMNSHO. If you havn't yet, I would highly recommend giving it a test spin.
Using the testing interface and following along on the cpan-testers mailing list is a great way to learn about what goes on up there on the front lines of Perl module development. Most of the high volume posts are automated uploads and test results, but every now and then you'll see an interesting discussion between testers and module developers as they try to debug failed tests.
()-()
\"/
`
| [reply] |
|
I've stopped using CPAN and am trying to stay away from CPANPLUS, mainly because CPAN always seemed to D/L a horde of Modules on first setup (which wasn't too bad in itself) but it also grabbed the latest version of Perl and made you get the latest version. This had bad side effects with some of the scripts which I was running. So I use make on all of the modules I install on the production servers I setup.
Does CPANPLUS have better dependancy handling?
BlackJudas
| [reply] |
|
|
| [reply] |
|
Some things are known about the name:
- It won't contain the word CPAN (Andreas did offer
the use of CPAN.pm provided there was some backwards
compatibility, but many people feel the name is
poorly chosen).
- It will be a top-level name (to protest top-level
names in general, talk to p5p not me ;)
The meaning it will attempt to capture is beyond the scope
of the Net:: modules. More time is probably spent
determining if you have the Net:: modules than using
them... At any rate, CPANPLUS is aimed more at
module management than just fetching.
/me is staying out of this entire quagmire of naming
and will just call it CPANPLUS until it gets another
name...
Ps. To comment on sauoq's post: CPANPLUS does allow
you to fetch modules from your local file system. I
can't say about CPAN.pm since I don't use it.
| [reply] |
|
Please, please, please, call it Net::CPAN. Then we can get CGI renamed Net::CGI.
Yuck. No. I wouldn't agree with either of those names. Both CGI's and CPAN's relationship to networking is peripheral.
CPAN uses various means to retrieve modules over the network but its real job is to determine dependencies, build, and install those modules. Certainly CPAN could have the functionality to access a local archive via the filesystem rather than the network. I don't use CPAN or CPANPLUS (I answered "make" on the poll) so for all I know one or both already have that functionality. It might be especially useful where institutions keep a local CPAN mirror and make it available to their user base via NFS.
CGI is simply a platform independent interface by which information servers may run external programs. In reality, this is only true for some definitions of "platform independence" and "information servers" but that's its stated goal.1 It currently requires that the external program knows some things about the protocol that the information server is using but the actual network communication takes place through the server itself.
So, I think putting either CPAN or CGI in Net::* would be a mistake.
I wouldn't mind seeing name changes for B and O though.
1That is, its the stated goal of the draft CGI specification not of the CGI module.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
|
I'd prefer something like Module::CPAN, Install::CPAN or Update::CPAN though I agree with your other reasoning (in later posts). As for CGI, well, how about Interface::CGI? *Grin*
Yes, that means I'd like to see the PPM module named Install::PPM (or whichever) instead too.
What I really would like to see is something like Module::Build get used. Like the guy says, what on earth is make doing in the install process? That is what usually causes me trouble when trouble does arise. (Nope. Haven't tried it. Just liked the idea. And it would be a good namespace to go under).
You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.
| [reply] |
|
Re: To install a module...
by joe++ (Friar) on Sep 27, 2002 at 07:37 UTC
|
perl -MCPAN -eshell
This just Works For MeTM, although I recognise the agony when accidentally trying to upgrade one of those core modules on a platform with an older Perl installed (this will pull the newer Perl source tarball and start installing right away...)
One more disadvantage is that I tend to miss the generally very well written example scripts that come with many modules. These end up somewhere below /root/.cpan/places-I-never-look
Have to look into CPANPLUS yet!
--
Cheers, Joe | [reply] [d/l] |
Re: To install a module...
by dada (Chaplain) on Sep 27, 2002 at 12:42 UTC
|
my personal poll results:
I use make: | @@@@@@@@@@@@@@@@@@@@@@@@@ 51% |
I use the CPAN.pm shell:
| @@@@@@@@@@@@@@@@@@@@@@@ 46% |
I write my own:
| @ 2% |
I use PPM:
| | 1% |
cheers,
Aldo
King of Laziness, Wizard of Impatience, Lord of Hubris | [reply] |
|
Results accurate to plus or minus seven percent, nineteen times out of twenty.
elbieelbieelbie
| [reply] |
Re: To install a module...
by blaze (Friar) on Sep 27, 2002 at 06:49 UTC
|
PPM is probably easier, but who likes change, good ol' make on linux for me...i tried to use the CPAN.pm once a while back, it was like 4 in the morning, i was half asleep, and whatever i did, it starting installing perl...on a P266 that takes quite a while, and at 4 in the morning i wasnt too happy, so i'll probably stick with make, its more fun anyway :-p
-Robert
Pointless Update: hehe, i've never been the first to vote before, i make up the 100% :) | [reply] |
|
| [reply] |
|
I was bit by that too. I believe that problem was fixed, or at least it will prompt.
-Lee
"To be civilized is to deny one's nature."
| [reply] |
Re: To install a module...
by ajt (Prior) on Sep 27, 2002 at 11:43 UTC
|
A bit unfair this...
I use CPAN shell when I can, make when I'm behind a CPAN unfriendly firewall, nmake on my NT box, and PPM when I need a Windows binary.
I must also confess to having hand copied files in the dim and distant past......
--
ajt
| [reply] |
Re: To install a module...
by tbone1 (Monsignor) on Sep 27, 2002 at 12:54 UTC
|
<python_yorkshiremen>
Ah, you kids today, with your modules and CPAN and hulahoops!
Why, back when I was a lad, we had to write all of our own C libraries, even stdio.h!
</python_yorkshiremen>
--
tbone1
As God is my witness, I thought turkeys could fly.
| [reply] |
|
| [reply] |
Re: To install a module...
by jepri (Parson) on Sep 27, 2002 at 07:03 UTC
|
I want fire-and-forget lemurs.
Update: I also want a device that monitors my blood sugar level and prevents me from posting when my levels go high and I go silly.
re the poll, I use CPAN exclusively. I plan to switch to CPANPLUS when it goes core though. ____________________
Jeremy
I didn't believe in evil until I dated it. | [reply] |
Re: To install a module...
by vek (Prior) on Sep 27, 2002 at 13:30 UTC
|
On my box - got root baby:
perl Makefile.PL
make
make test
make install
And for those occasions when I'm far to impatient to wait for the sysadmin to install modules on boxes where I don't have root access:
perl Makefile.PL PREFIX=/some-dir LIB=/some-dir
make
make test
make install
--
vek
-- | [reply] [d/l] [select] |
(tye)Re: To install a module...
by tye (Sage) on Sep 27, 2002 at 23:50 UTC
|
Sorry, I had meant to include the RPM/apt-get option but originally forgot to. I've added it now. So, those foolish enough to consider these numbers of statistical significance should take into account that for about 17 hours, the RPM/apt-get option was not available.
Thanks to rinceWind for suggesting this poll.
- tye (I have CowboyNeal install my modules)
| [reply] |
Re: To install a module...
by zakzebrowski (Curate) on Sep 27, 2002 at 12:32 UTC
|
perl Makefile.pl , because you can do /n?make test/. Especially when you have to deal with multiple operating systems and you are not guaranteed the version of perl that you have on that machine. (Welcome to my world...)
----
Zak
"There is no room in this country for hyphenated Americanism" ~ Theodore Roosevelt (1915) | [reply] |
Re: To install a module...
by jwest (Friar) on Sep 27, 2002 at 15:04 UTC
|
For me, it depends.
Most of the time, I use the CPAN shell. Especially for a module that I'll only want on my machine for a limited amount of time. I've got my environment all set up with a ~/.cpan/CPAN/MyConfig.pm to build and install modules in a ~/.perl subdirectory, and corresponding environment variables so that my one-off scripts use it just fine. I don't even need to be root. Cool.
Sometimes the module I want is already packaged in the Debian distribution. So, I apt-get it instead. Even cooler.
Sometimes the module I want isn't packaged by Debian, but I need it enough that I want to install it properly so that all users of my system will have access to it. For that, I make a .deb out of it myself with dh-make-perl. Very cool.
What it all comes down to is, I've got way too much free-time.
--jwest
-><- -><- -><- -><- -><-
All things are Perfect
To every last Flaw
And bound in accord
With Eris's Law
- HBT; The Book of Advice, 1:7
| [reply] |
|
Bah. I just got finished writing a terrible hack of somthing like this. (Mine does do some things that dh-make-perl doesn't do, but nothing major.) Mine is ugly as all hell (see my scratchpad for a somwhat out-of-date copy of the code iff you're reading this fairly close to when I wrote it), though.
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply] |
RPM modules?
by Jeppe (Monk) on Sep 27, 2002 at 13:39 UTC
|
I like to have modules available on RPM *ducks*. Simply because my customers dislike having the modules exist outside of a 'rpm -qa' grep. To them, simply having an RPM means maintainability (it does to me too). So - anyone got any secret, magic scripts for RPM-ifying perl modules? Relevant experience? | [reply] |
|
| [reply] |
Re: To install a module...
by hiseldl (Priest) on Sep 27, 2002 at 15:04 UTC
|
Linux: perl -MCPAN -e shell 100%
Win32: ppm 80%
perl -MCPAN -e shell 20%
I use PPM on win32 boxes when the module is available. If there is a newer module on CPAN than PPM shows, do not install it! I've been bitten by this too many times, what happens is that there is probably some unsupported feature in the CPAN module and that's why activestate hasn't updated there PPM repository yet. Otherwise, if the module I want doesn't exist in the PPM repository, I'll use CPAN shell.
YMMV.
-- hiseldl What time is it? It's Camel Time! | [reply] |
Re: To install a module...
by alfie (Pilgrim) on Sep 27, 2002 at 08:14 UTC
|
Can't vote, sorry -- there is neither an "other" nor an "apt-get install" option ,)
--
use signature;
signature(" So long\nAlfie"); | [reply] |
|
Except the "I use RPM/apt-get/etc. " option.
:^)
--
Brother Frankus.
| [reply] |
|
Wasn't there when I voted, sorry. I really don't think that I missed it. Thanks for the hint, though.
--
use signature;
signature(" So long\nAlfie");
| [reply] |
Re: To install a module...
by moxliukas (Curate) on Sep 27, 2002 at 14:45 UTC
|
I usually get my modules via CPANPLUS, but just yesterday I found one module that I might need to rewrite for myself. Specifically it is XMLRPC module, but it requires SOAP::Lite, and XML::Simple which needs expat and so on... Too much trouble for making a simple XML-RPC call.. I'll robably end up doing it via Net::HTTP module and parse XML myself. All I need is just one XML-RPC call anyway ;)
| [reply] |
|
- Simple hardcoded xml-rpc call.
- Multiple hardcoded xml-rpc calls.
- Small parser for xml-rpc calls.
- Large parser.
- Ugly code. Replace with module.
- goto step 1
--Penguin of Doubt
| [reply] |
Re: To install a module...
by silent11 (Vicar) on Sep 27, 2002 at 13:06 UTC
|
PPM here. At lease on my windows box.
When I'm on Linux I use make, but it always makes the modules to some ./blib directory. How do I get make to build where I want?
-Silent11 | [reply] [d/l] |
|
You want to run 'make install' as well.
Read the man pages for MakeMaker (man ExtUtils::MakeMaker) for other options. Also, depending on your OS flavor, there may be some standards for where you should install modules to.
For example, on debian systems you'll want to use:
perl Makefile.PL 'INSTALLDIRS=vendor'
On RedHat systems, I use:
perl Makefile.PL 'INSTALLDIRS=site'
Cheers,
-Dan | [reply] [d/l] [select] |
Re: To install a module...
by shadox (Priest) on Sep 27, 2002 at 15:44 UTC
|
Most of the time i am on my FreeBSD box there i use CPAN.pm and it works just perfect for me, in my XP box i use PPM even when i don't like too much the idea cuz i don't like to use pre-compiled stuff in openSource software, but anyway it works ok so far, then i can live with it. :)
___________________________________________
Optimus magister, bonus liber
| [reply] |
Re: To install a module...
by Helter (Chaplain) on Sep 27, 2002 at 14:57 UTC
|
I've recently installed gentoo linux, and if the module is available through the emerge functionality I use that. Otherwise it is the CPAN shell for me. | [reply] |
Re: To install a module...
by Rudif (Hermit) on Sep 27, 2002 at 23:25 UTC
|
I can't choose because I use several of above
* ppm
* nmake :-(
* move a module
* cut'n'paste
* write my own
and I always write the whole truth and nothing but truth, in programming matters.
For why would a Perlmonk ever try to deceive a Perlmonk, or a compiler for his favorite language?
Rudif | [reply] |
Re: To install a module...
by v_thunder (Scribe) on Sep 27, 2002 at 15:17 UTC
|
I use different methods depending on how in a hurry I am.
First, I'll try to find a package for my OS flavor. Failing that, if I'm in a hurry I'll use the CPAN shell. But If I have a couple of minutes, I'll whip up a quick package of the module--it's usually fairly easy to do.
I'm not sure where that falls with the options provided, though..
Cheers,
-Dan
| [reply] |
Re: To install a module...
by Dog and Pony (Priest) on Sep 30, 2002 at 21:25 UTC
|
On Windows I use PPM, CPAN.pm, manual tarball, and just copy the blasted files, in that order. Steps two and three do depend on having obtained nmake or something like that on that particular machine though. Sadly pmake doesn't work (for me at least).
PPM tip of the day (1): PPM in 633 seems to have a somewhat strange bug where it won't install some modules claiming it can't find a suitable implementation. Try describing the module then installing it again. It will (if there actually is a Win implementation) then install. Strange.
PPM tip of the day (2): If you install modules any other way than via PPM, and sometimes even when you do, the otherwise excellent HTML docs will not update to reflect this.
perl -MActivePerl::DocTools -e ActivePerl::DocTools::UpdateHTML();
will walk all your modules regenerating the docs from the POD. Most useful.
On *NIX I use CPAN.pm, tarball in that order. Haven't so far had to go any further than that.
As mentioned in another post I made further up, to be as totally cross-platform as Perl wants to and should be, someone should get rid of that stupid make part though. That is the problem that should be addressed first and foremost, not that CPAN.pm is slightly buggy. It is a *huge* hassle for beginners to even obtain a make and then get it to work, and PPM rarely has all modules you need. Even if PPM did, and even though PPM is available for several platforms, why can't there be a Perl-only installer that is core everywhere? Make is fine for me, now. Mostly. I recall how much trouble that was and I'm sure lots of others are going through the same right now.
Lots of people are talking about CPANPLUS. I never got it to work, but that was a long time ago, so I'm sure it works now. I'm not sure what it is that makes it so good though. I must look that up. Does it still use make/nmake/etc? If so, I wonder what is the benefit, because that is the only part that fails (when something fails) with CPAN.pm for me. Like I said, I will have to look the facts up.
You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue. | [reply] [d/l] |
|
| [reply] |
|
PPM> search Foo
Which returns the result
1. Foo
2. Foo::Bar
When you then try 'install 1' to get Foo installed, you get the error message "No suitable implementation found" or some such. Then do 'describe 1', followed by another 'install 1'. Describe does list what platforms are available, and if 'MSWin32-x86-multi-thread' is not in the list, you are out of luck. Many times though, it seems PPM doesn't really check for this, but the describe forces it to do so, making the installation succeed.
And yes, you can do 'describe Foo' directly instead.
Hope that helps.
You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue. | [reply] [d/l] [select] |
Re: To install a module...
by jeorgen (Pilgrim) on Sep 30, 2002 at 09:09 UTC
|
Does anyone have a recommendation for a setup on Windows with a C compiler that will work with most C code containing modules from CPAN? Preferable a free one. About three years ago a non perl colleague tried to help me with installing a C compiler for this purpose but we got lost in the land of compiler flags. (I've got and use nmake already),
Cheers
/jeorgen | [reply] |
Re: To install a module...
by NicS (Scribe) on Sep 30, 2002 at 11:41 UTC
|
What about dh-make-perl then dpkg ? I guess it is sort of make and RPM/apt-get/etc rolled into one!
--
Nic | [reply] |
Re: To install a module...
by spacewarp (Pilgrim) on Oct 01, 2002 at 20:06 UTC
|
Given that I almost never install a new module, I had to consider the one I did.. my own. And I keep improving it. So, I generally cut and paste. 8)
And my addressbook program is a Perl-glorified textfile and grep. As God meant it to be.
Spacewarp
DISCLAIMER:
Use of this advanced computing technology does not imply an endorsement
of Western industrial civilization.
| [reply] |
Re: To install a module...
by belg4mit (Prior) on Oct 03, 2002 at 02:36 UTC
|
I replied make however it's actually...
# whoami
belg4mit
# perl -MCPAN -e 'make Foo::Bar'
# su
% make install
I prefer to keep copies of everything I install,
and intermediate files as non-root.
--
perl -wpe "s/\b;([mnst])/'$1/g"
| [reply] [d/l] |
Re: To install a module...
by fredopalus (Friar) on Oct 03, 2002 at 21:52 UTC
|
I use PPM, it's very easy to use. | [reply] |