•Re: (kudra: CPANPLUS) Re: To install a module...
by merlyn (Sage) on Sep 27, 2002 at 21:42 UTC
|
In my first attempts to use it, I noticed:
- There appears to be no "setting" for "current CPAN archive", so I'd have to go through the whole interactive setting thing just to point differently depending on whether I was online or at 30,000 feet. Ick.
- I didn't see that it ever reloaded the index files, and that I'd always have to do that manually.
Both of these will prevent me from using this module on
a regular basis.
Is there a person or persons I should write with this feedback?
-- Randal L. Schwartz, Perl hacker | [reply] [Watch: Dir/Any] |
|
#!/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] [Watch: Dir/Any] [d/l] [select] |
|
OK, so the answer to the first one is that CPANPLUS assumes a policy of "reload after one day" instead of CPAN.pm's "reload after a user-specifiable period of time". That makes sense, but wasn't documented yet.
As for the second, no. I'm talking about the CPAN
mirror setting, like getting the CPAN from http://www.cpan.org/ when I'm online, or getting it from my file:///Users/merlyn/CPAN/ when I'm offline. In CPAN.pm, that's a simple "o conf urllist unshift BLAH". But there appears to be only a very truncated list of settings in CPANPLUS (so far?),
and "current CPAN" is not one of them.
It has nothing to do with FTP proxy settings.
-- Randal L. Schwartz, Perl hacker
| [reply] [Watch: Dir/Any] |
|
Re: (kudra: CPANPLUS) Re: To install a module...
by ignatz (Vicar) on Sep 27, 2002 at 21:38 UTC
|
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] [Watch: Dir/Any] |
|
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] [Watch: Dir/Any] |
|
CPANPLUS should work with core Perl, although it is a lot
happier if you will let it install some modules during
setup, especially on machines where it might be difficult
to use binaries. Certain options, such as md5 checks,
require that module be installed. However, if you don't
want these modules installed you can decline them during
configuration (if you do want them, CPANPLUS will handle
the installation before it installs itself).
As for the normal prereq handling, CPANPLUS allows you
to select whether you should always follow prereqs,
never follow prereqs, or prompt for each.
CPANPLUS will decline to install new versions of Perl.
It will let you download them, if you like, but because
Perl should be installed quite interactively, CPANPLUS
insists you do it yourself.
One advantage you may find to CPANPLUS--which I mention
since you talk about production
servers--is the programmer's
interface which makes it easier to maintain modules on
multiple machines. You can set up an install script to
install the same modules on multiple machines (and handle
known issues with modules and the like). CPAN.pm does
allow this, but by poking through the shell. By
comparision CPANPLUS is a lot cleaner, since it was
designed with the programmer's interface in mind (shells
are just layers on top of the interface). Check out
Backend
for more information on the programmer's
interface. It's worth noting, however, that this
is version .036, and the interface changes significantly
(which it may continue to do until release 1.0)
in the upcoming .04 (in particular, return values become
objects).
| [reply] [Watch: Dir/Any] |
(tye)Re: CPANPLUS
by tye (Sage) on Sep 27, 2002 at 23:44 UTC
|
Please, please, please, call it Net::CPAN. Then we can get CGI renamed Net::CGI.
- tye (I don't supposed you can rename B and O also)
| [reply] [Watch: Dir/Any] |
|
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] [Watch: Dir/Any] |
|
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] [Watch: Dir/Any] |
|
Sorry, your claim that CGI.pm isn't for networking is, well, silly.
As for CPANPLUS, if they want to keep "CPAN" in the name, then the primary way they are going to attach to CPAN is via a network. I don't mind in the least if they decide that this is not really the central purpose of the module and call it something having to do with "module management" or whatever.
But the point is that the only modules that don't have "::" in their names should be all-lowercase, that is, pragmas. See Filehandles vs. Packages: And the winner is... for one good reason why.
Other reasons include the "I used CGI" problem. Having a "::" in a module name can avoid a lot of confusion.
- tye (but I plan to switch to "Person::Tye")
| [reply] [Watch: Dir/Any] |
|
|
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] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |