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
