minicpan 162.52s user 17.89s system 70% cpu 4:17.36 total
minicpan2 29.35s user 1.74s system 62% cpu 50.064 total
Above is my very unscientific speed comparison of minicpan (as released to CPAN) and minicpan2 (as sits in my Subversion). I know minicpan2 will get slower as time goes on and I add the same features (and more) that minicpan already has. Those features, though, are not going to slow it down more than a few more seconds, I think.
Right now I still have minicpan2 existing as a script that does its own thing. I'm about a third, or maybe half, done with the modules that will do the same work more generically. CPAN::Mini::Archive represents an archive of modules (it's the SPA mentioned earlier). By default, it assumes you're going to point it at a URI to the root of an archive with the normal 01mailrc and 02packages files. I am pretty close to just declaring I won't handle 03modlist; I don't feel like writing a parser, and I don't intend to just eval code received from the network.
Anyway, CPAN:Mini::Archive works. CPAN::Mini::Archive::WriteIndex (the name of which is not set in stone) also works, writing out index files from a C:M:Archive object. Now I get to write the merger and mirrorer. Their trivial forms exist, of course, in the minicpan2 script. I just need to go ahead and write their less trivial forms.
I'm not sure that CPAN::Mini v2 will be CPAN::Mini. It might be CPAN::Mini2, or something else. I don't want to put myself in the position of releasing a same-named module that isn't compatible with previous extensions, especially after being among those who ranted about Apache:: in mod_perl 2. Of course, if I can provide a similar enough interface, it's not an issue.
This kind of situation makes me feel that I'd like a more standard option for formal interfaces. Of course, even if I had the ability to write both an interface and implementation, the problem would remain: I wouldn't have realized that I'd want to change things in this specific way. Maybe the lesson in the future is to start with more leading underscores, and to remove them less readily.
We'll see what happens. I guess CPAN::Mini might have a simple enough interface that I can make it a wrapper for CPAN:Mini::2.
Re: minicpan, minicpan2, and module naming
mw487 on 2005-03-14T14:00:03
(1) Does CPAN::Mini have a nice set of tests? If you pass the same tests, faster, that is good enough for me. Then naming should be much easier.
If you don't pass certain tests, note those.
If it does not have a nice set of tests, it would be nice to add to its test suite, and then GOTO (1).
Re: minicpan, minicpan2, and module naming
rjbs on 2005-03-14T14:29:43
It doesn't, but I might add them retroactively. I've built a fake CPAN archive with a nice small set of files and indices that could be used to test. I'm using these to test CPAN::Mini2, and I had originally planned to test CPAN::Mini with this kind of thing.
Why CPAN::Mini is not Apache::
Alias on 2005-03-15T01:30:21
Of course, the big difference here is that CPAN::Mini is quite young and all the people that have built things on top of it (including me) are both more skillful and don't use it in a heavily commercial setting (for the most part | yet).
And can I add "PLEASE make CPAN::Mini easier to subclass and add hooks all over the place this time?"
public SVN repo
markjugg on 2005-03-27T21:25:26
I'm having trouble getting minicpan to work, and am thus interested in minicpan2. Does the SVN repo where it lives have a public address?
If you are interested, here is the unintuitive output I get when trying minicpan:
# minicpan -l
/usr/share/mirrors/cpan -r ftp://ftp.uwsg.iu.edu/pub/perl/CPAN/
authors/01mailrc.txt.gz
ftp://ftp.uwsg.i
u .edu/pub/perl/CPAN/authors/01mailrc.txt.gz: 500
modules/02packages.details.txt.gz
ftp://ftp.uwsg.iu.edu/pub/perl/CPAN/mod
u les/02packages.details.txt.gz: 500
modules/03modlist.data.gz
ftp://ftp.uwsg.iu.edu/pub/perl/CPAN/modules/03m
o dlist.data.gz: 500
########
It could definitely use a more friendly response there.
Actually, now that I try it again with the same syntax, it works.
Thanks for your work on this. It's helping to make me a happier laptop user.
Mark
