[Distutils] Distutils integration

[T-Methy Moddletin]

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
 ~`~`~'~`~`~'~`~`~'~`~`~'~`~`~'~`~`~'~`~'~'~`~'~'~`~'~'~`~'~'~`~'~'~`~