Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See also debian's apt-get.
Which brings me to my pet peeve- I think it's time to start doing binary packaging in CPAN, for those who don't want to bother with compilation. That has interesting implications for how we deal with paths, but still, I think it's worthwhile. Of course you would want to support source as well, but having binary available for those who want it just seems like a darn good idea. Of course there would be issues of who's providing the binaries, how they are built, how external dependencies on third-party libraries are managed, etc, but still, I think it's worth looking into. It might not be a problem that's worth solving, in the end, but I think it's one worth giving serious thought to. --Josh At 23:38 on 06/04/2002 EDT, "Miko O'Sullivan" <[EMAIL PROTECTED]> wrote: > [This seems like a good time to post something that's been on my mind for > some time.] > > SUMMARY > > The world needs a really easy CPAN client. Here's one design for such a > thing. > > DETAILS > > A few brief philosphical points: > > 1) People like languages that have tons of built-in > doohickeys. See PHP and Java. > > 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. > > 3) The current CPAN.pm isn't really easy to use. Now matter how > simple it may seem to the Perl Guru community, inexperienced > users find it intimidating to download CPAN modules. > Remember: beginners end up ruling the world. See Microsoft. > > Solution: a simple program that is called from the command line. Here's a > brief tour: > > Download and install a module from CPAN. Loading a module also automatically > loads its dependencies. > > cpan load Date::EzDate > > 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 > > Update a module. > > cpan update Date::EzDate > > Don't download dependencies: > > cpan --dep 0 load Date::EzDate > > Update all currently installed modules: > > cpan update * > > Update a namespace: > > cpan update Date::* > > Get help on using cpan: > > 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 > > Get from a particular FTP server > > cpan --server cpan.idocs.com load Date::EzDate > > 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 > > Optional verbose mode > cpan --verbose load Date::EzDate > (hundreds of lines of lovely make messages) > > Request particular operating system compilation (e.g. Win32) > (usually not needed explicitly because cpan.pl will know which compilation > to ask for) > > cpan --compile win32 load Date::EzDate > > Indicate latest development vs. latest stable > > cpan --latest beta load Date::EzDate > > Remove a module > cpan remove Date::EzDate > > > ----------------------------- > 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... > > - Run-time dependencies: Dependencies can be indicated explicitly with > something like this: > > use Dependency Date::Language::French; > > - CPAN conformity: All modules served from CPAN must meet certain > specifications. They must include a version, POD, license statement, and > probably other meta-info. The meta-info would be standardized so that the > system could tell that the module conforms. > > - 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. > > - 6pan.org: The domain name 6pan.org is available as of this writing. Larry, > are you planning on saying "6PAN" enough to merit somebody registering > 6pan.org? > >
