From: Ben Tilly Date: 2000-12-18T08:00:45+09:00 Subject: [ruby-talk:7520] Re: Ruby RAA "Joseph McDonald" wrote: > >Thanks for the excellent input Ben! You are welcome. One point I think that cannot be made strongly enough. What matters is not just having things there, but rather having confidence that the wheels which are there, will work as advertised. Also while CPAN is often cited and does indeed work well, IMHO Debian (http://www.debian.org/) has tackled a similar problem and done a better job. > > 1. Have a core team managing the namespace, testing, and > > telling people about duplicated functionality. > >Does CPAN do that? I see a lot of duplicated functionality. >not that that's a bad thing, different strokes for different >folks I always say. But a nice summary of similiar modules >by an impartial would be nice (witness the numerous templating >modules on CPAN... how do you pick?). Yes, there is a team of testers that serves an advisory role. They mainly test whether it builds on different platforms, and tell the author about similar modules, and advise on possible namespace conflicts. Authors still decide whether or not to proceed, and frequently do if they think that their module does something different. How do you pick a templating module? Well I listen to Randal Schwartz and pick Template::Toolkit. :-) Seriously do take a look at it. Of all of the template solutions to emerge in the Perl world, it is by far the best. If Ruby wants to produce its own templating solutions, that one would be an excellent model to work from. (I think that second is Text::Template. But it is far less flexible.) See http://search.cpan.org/search?dist=Template-Toolkit for details. > > 2. Have a standard tool ("perl -MCPAN -e shell") to interact > > with CPAN. > >Agreed! What makes it *king* is the dependency checking and >automatic installs of dependencies. (although it doesn't always work...) Likewise look at Debian. > > 3. Have the standard installation save important local > > information in a way that module authors can use. > >you mean for bug reporting? That or for installation. Try "perldoc Config" and take a look at what is available. All of that information is captured by Perl at install time, and when you try "perl Makefile.PL" any and all of that information can go into the makefile. > > 4. Have a standard directory layout decided at installation > > for where things go. > >agreed. key. > > > 5. Have a standard method of inlined documentation, > > automatic regression tests, etc. > >key. especially the regression tests. > > > 6. Have a standard packaging tool (h2xs) for producing > > modules in a standard format. (Making the entire > > "make Config", "make", "make test", "make install" > > process standardized across modules.) > >would probably have a huge impact on people placing their work on >RAA. the biggest drag is getting something "distribution ready" >pure grunt work, rubyites (and perlites) don't want to be bothered >by such drab work. Exactly. When you look at CPAN, the parts of the proceedure made automatic by h2xs happen consistently. The parts that do not are inconsistent and often don't happen. Likewise take a look at Debian and debmake. Debian is a very consistent system despite being put together by a distributed group, and a large part of that is having clearly decided policies on where things go, and a standardized packaging tool that makes it easy to follow that policy. > > 7. Have a standard way to check versions, state > > dependencies, and so on. > >Do you mean that the user could say: puts $class.version; $class.depends ? Perl doesn't do a great job on this. But if you assign to $VERSION in a module, then people requiring the module can put a version check into the load, and the CPAN tool can detect whether or not your version is sufficiently up to date. But this is optional and doesn't happen as consistently as it should. Debian does a much better job on this. They have a standard packaging format for their package (the .deb archive) that carries version information. > > 8. Have a standard tool to check whether you have > > indeed done it right. > >okee dokee For instance if you say that your dependencies are Foo and Bar, it should load your module and see if there is some other Baz out there that you are loading as well. :-) > > 9. Have a standard bug reporting mechanism for installed > > modules. > >Amen. Perl doesn't have this and really, really needs it. Debian does and it really works. It is critical to be able to go to a single place and browse open bug reports. It also is an excellent way to detect when something is not really being maintained any more. Today there is no good way of finding out which CPAN modules are buggy and which are not. There is no good way to find out whether someone has already pointed out the bug which you have to report. There is no good way for an eager volunteer to find out what needs to be worked on. I cannot stress enough that Perl got this seriously wrong. And once people have their own ways to handle these things, it would be very hard to just go and say, "OK, here is the new bug-tracking system, everyone has to use it." This has to be gotten right from the start. >I'd add the obvious: good search mechanism and good hierarchical >organization. CPAN has that (although it does break more than >it should IMHO). Yes. >Also, I know there is a movement to categorize applications as well >as modules on CPAN. That is also a good idea. Another shortcoming. CPAN's system is only good for modules, which is one reason that there has been room for some of the other application archives out there... A final note. The most successful model to emulate IMO is Debian, not CPAN. Cheers, Ben _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com