j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On 28 April 1999, Mark Hammond said:
How far do we go :-)
Personally, I would simply like to see the distutils SIG solve this problem for us. (sure). Eg, the "build" or "install" process (depending on the OS) could build a local HTML file with knowledge many "common" extensions - a single click, and it is downloaded, configured and built. Oh well, back to reality...
It's not impossible, it just takes a while. I think it took the Perl community about three years to go from "hey! let's have a standard build mechanism for modules!" to the point where I can install (almost) any module from CPAN with one shell command:
perl -MCPAN -e 'install ("MIME::Base64");'
which is insanely cool. (It took about two minutes to do the above just now; that included trying two CPAN mirrors that aren't being cooperative this morning, finding one that was working, downloading the current module list from it, determining that there is a more recent version available than the one installed here, downloading it, unpacking it, running "Makefile.PL" to generate the Makefile, running "make" [which compiles any extensions in the distribution, copies all the .pm files around, and generates the documentation], "make test" [run the module's self-test suite], and "make install" [install it in the "site-perl" library directory]. Amount of user interaction required: typing the above command line.)
It's still rough around the edges, though, especially when building a new installation from scratch -- mainly because Perl doesn't ship with ftp or http libraries, so the CPAN.pm module has to try downloading stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and installed the libnet and libwww-perl distributions. That's one problem we won't have with Python, at least. Oh yeah, and it all works great under Unix... but the rest of the world lags behind.
Also, two major components of being able to do this -- the Perl Module List and CPAN -- are still vapourware in Python-land. But hey, if we can get to the "we have a standard build mechanism for modules!" point, then all the rest becomes a lot more feasible.
Pep talk over...
Greg Ward - software developer email@example.com
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913