Hmm... I like it. It took me a good 6 months before I learned how to use CPAN. I don't see how your proposal is that different from:
alias cpan='perl -MCPAN -e shell' But I get the idea. Someone (well, you've inspired me now, so I) could write a perl5 equivilent, because command line is quite nice. I'll see how it flies with my next class. More comments below. On Tue, 4 Jun 2002, Miko O'Sullivan wrote: > [This seems like a good time to post something that's been on my mind for > some time.] Sure. It's been pretty dull around here. > DETAILS > > A few brief philosphical points: > > 1) People like languages that have tons of built-in > doohickeys. See PHP and Java. See Perl 5 (though PHP and Java far exceed it, in doohickeys) > 2) Instead of a huge standard library, a really easy to use CPAN > client allows programmers to have the world of modules almost > as easily as built-in, and with the advantage of up-to-date-ness > and quantity. Indeed. And it should be _really_ easy to install to a different source tree and have Perl use it. I want more modules on systems I don't administrate, and asking for them is a pain. > The command above would ask the user if they want to install using the > current directory as the root of library tree, and is also mentions that if > they want to specify another dir they can use this command: > > cpan --lib ~/lib load Date::EzDate Hmm... yeah, I think that's as easy as library root's gonna get. I like C<install> better than C<load>, though. > Don't download dependencies: > > cpan --dep 0 load Date::EzDate So, what's the difference between --dep 2 and --dep 3? Is that depth or something? Or max number? > Update all currently installed modules: > > cpan update * Oh, if only shells could DWIM... Naturally this would do cpan update and then every file in the current directory. To remedy this you have to do some awful thing like: cpan update \* or cpan update '*' Maybe 'all' would serve the purpose better. > Update a namespace: > > cpan update Date::* I like that idea a lot. > Get help on using cpan: > > cpan help Err, howsabout the GNU way... cpan --help > No configuration files (.e.g .cpan) are necessary. However, you can use a > configuration file if you want tp indicate a .cpan-like file > > cpan --conf ~/.cpan load Date::EzDate What about no configuration file if ~/.6pan's not there, and ~/.6pan if it is. > By default, progress messages are kept to a minimum. No more of those > hundreds of lines of bewildering make messages. > > cpan --lib ~/perllib load Date::EzDate > finding server > downloading module > determining dependencies > downloading dependencies > installing > done We could just go with the idiomatic "don't say anything unless it's bad." I've developed a taste for that. Perhaps this is better for the default and you can enable quiet through ~/.6pan. > ----------------------------- > Other Misc CPAN Ideas > > - Authors don't need to indicate dependencies. CPAN figures it out from the > use's and require's. CPAN will not accept modules that depend on other > modules that aren't on CPAN. (Yes, there might be a chicken and egg problem > there, I'm sure we can find a solution.) This leads me to... What about version discrepancies? I guess that can come from the C<use>s. > - Automated load balancing: cpan.perl.org doesn't have to pay for the > bandwidth of the whole world. cpan.pl should recognize a command from > CPAN.org to redirect to another server. Definitely. I like on-6pan mirrors better than on-client mirrors. About the name 6PAN... I mean it reads well, but does it mean anything? The, er, 6 Perl Archive Network? RCPAN? Really Comprehensive Perl Archive Network? :) Or just PAN? I got nuthin'. Luke