Mon, 29 Nov 1999 08:57:02 -0500, Greg Ward <gward@cnri.reston.va.us> wrote:

Cool... BUT I worry that having multiple Python archives or meta-archives might be as bad as having none at all.

Ouch. (-: Ah well, since this is the state of things, at least we may as well have a way to more conveniently search for what's out there. And of course the thing about "meta-archives" is that the "meta" can represent just about anything. Therefore, if one day someone wants to suddenly start archiving everything on a central server, i can just as easily change all the pointers to there ---- or add extra pointers to there as well as the ones that exist. (Not that necessarily anyone would want me to <G>).

Oh well, that's the mess the Perl world was in five years ago before Jarkko Hietaniemi came along and cooked up CPAN.

Hmmm, i'm not familiar with pre-CPAN Perl. Perhaps you could enlighten me? What exactly was the nature of the "mess"? Perhaps there are other ways than CPAN to address some of the problems? Non standard packages? (You're taking care of that problem, i hope!) But perhaps non-standard naming as well. Hideously ugly, eyeball splitting web page colours and designs? (even more eyeball splitting than perl code itself?! <G>). Broken links? (This last thing I have found already to be a perpetual problem. Even though I have tested most of the links I have added to my database, which is mostly less than two months old... already broken link reports stream in! It has me thinking of cooking up a link checker to periodicially go and automatically check links (python sure makes things like this easy to do!)... and perhaps (oh what devil put this idea in my fevered brain!) even after a certain period of brokenness generate an automated SPAM message informing the resource owner of my consternation! No mercy for people who leave broken links! Or at least sweap the database and segregate and flag broken links to make things less frustrating for hapless browsers who wander by. At least if the database became more known and used, authors may be more contientious about keeping their links up to date---this does not mention the pool of helpful users who may be able to assist in tracking down the lost gems... already in one case, at least, a helpful visitor has fixed one of the links in the 'lost/broken' directory.) No, in my opinion (which may not be worth much) there is one thing at least worse than having a meta-archive... and that's having ftp.python.org/pub/python/contrib/ ! No offense ment to anyone! But that place has become a terrible mess. And i hate README files! We might also recognise our potential different focuses. I presume your thinking resolves from your project of "packaging" and "distributing" (a.k.a. Social Engineering, as you say!)---where naturally a more controlled central archive would be the ideal. My perspective is generated less from caring what the actual resource is, or how to access it, acquire it, build it, and install it, but simply to find the damned thing in the first place! (-: Of course if there was a central archive, that takes care of finding things as well (assuming everyone wants to bother with going to the trouble of getting archived there). Still I must dissent. In retrospect, I am not fond of CPAN. I do not miss it. I do not consider it a model for emulation. It had perhaps some useful attributes----but I am (and hopefully I don't just say this because it is the nature of my-project-which-i-must-protect) genuinely in favour of decentralised resources. I think it's more encouraging to people to directly and easily control and release their stuff (and for those who want to upload somewhere there is still ftp.python.org!) While there are certain weaknesses and logistic complications (and yeah, perhaps "mess" also!) it seems a much freer environment to me. Less stuffy, as it were. Less official! Perhaps my biases are showing a little too strongly. I find the rigidity of CPAN just a little too intimidating, in fact. Let me put it another way which may ultimately damn me (if i haven't been damned already): CPAN to me FEELS a little too much like EMACs. (-: Yes, EMACs is a fine tool, and i've often wished i could figure the damned thing out! Many people use it to good (yeah, i concede perhaps even superior) advantage. But for many of us, we just find it continually baffling, bogglingly complicated, requiring too much. Nay, i fly back to VIM which is as far as i go. Likewise i fly from CPAN to a Vaults of Parnassus like place with pleasure. Others may disagree. It must be admitted also that I am not a professional (or even schooled in any way) programmer---there may be elements to these things I do not understand. I should be more ashamed of my ignorance than I am, except if nothing else perhaps I can represent the "unwashed masses" of pythong programers... under the banner of Guido's wonderful (even if a little grandiose) "Programming for Everyone" essay! As long as Guido clings to this crazy utopian ideal, you'll have to put up with amateurs like myself. (-: I have never used as CSV in my live-long life. And it probably shows. (-: I see all the strange $ codes in people's source and i think: wow, that looks impressively obscure and archane, someday i'll have to figure that out! However, i'm open to all these ideas. I have nothing intrinsically against a central archive, and would certainly welcome it (and happily index it---for myself, if no one else) --- let me know when you open one. (-: Already i note these quibles in the last few messages about version number parsing. When creating the Vaults of Parnassus database I had considered whether to have a seperate version field. I finally decided against it. It seemed to me a needless complication. Also i feared any benefits from it would be lost by non-standard version numbering systems.... and betas, and alphas, and everything else. So i just kept a plain title field, where the version number is tacked on the end of the string, as one sees printed. Now reading the discussion here I am thinking perhaps a seperate version field is useful after all.... i had not thought of it from the perspective of standardisted distributions and specific version querying. Perhaps if I used CSVs i'd be more aware of these issues. (-: But still for my purpose I think i can get away with no seperate version field. If it comes down to it, if necessary, I could always do a search for the software name, and parse out the version from the end of the title. But it's interesting to think about.

I think this is probably a documentation problem. Yes, the code is fairly complex, but that's because I wanted it to be fairly easy for

Yes, as mentioned above, you have many concerns that probably go far beyond my wildest needs or imaginations. I in no way mean to bash the complexity; but only also to weakly plead for a little more attention to the simplicity side as well. Thanks for your thoughts. We shall see what happens. Sorry to ramble so much! -- .._,.,._.,.,.,_,._,,,.,_,.,_,..,..,_..,.,.,_,,.,.,_._.,_.,.._,.,_..,. Tim Middleton =-=-= not all who wander are lost =-=-= x @ veX . net ~`~`~'~`~`~'~`~`~'~`~`~'~`~`~'~`~`~'~`~'~'~`~'~'~`~'~'~`~'~'~`~'~'~`~