[Distutils] Distutils integration

[T-Mathy Meddleton]

On Mon, 29 Nov 1999 at 1:18pm, Andrew M. Kuchling wrote:
> One field that might be interesting is, for lack of a better name, a
> 'status' field that said whether a project is maintained or
> unmaintained.

In fact (i'm happy to say) i have exactly such a field. And for lack of
a better name, it is called exactly that. (-:

It is non-obvious. My approach (though perhaps wrong-headed in some
places) has been to omit any unnecessary information from display (a
bit of an interface pet peave of mine is "too much cluttering useless
information"---so i may err too much in the other direction). Since
the status is set by default to "Alive and Well" on nearly all the
items in the database i consider the info redundant and it is not
printed. However, as soon as the status changes from Alive and Well,
it shows up.

I should explicitly document this behavior somewhere (at least), and
make a display showing all possible fields.

You can see this in the "Lost/Broken" category where i've dumped items
with broken links... they have a status flag to that respect... on the
details for each of them you'll see the "status" item appear... in
bright red letters even... (hopefully to attract someone's attention
who can fix the link --- have fixed many already --- many that remain
broken sadly on python.org --- i should be keeping track and inform
them... but it's hard to keep track... i think now though of Lyntin,
and X Extensions --- two recent ones that come to mind --- it is
heartening at least to see people actively making the effort to use
the "report dead link" function on my detail pages.)

In fact the flag is an integer and there's about 6 statuses possible
at the moment (though i'm wanting to refine this and have modified it
a few times already).... (excuse my even worse dictionary name than
field name <G>)... generally they go from best to worst condition...

    statuses = {
        0: 'Alive and Well',
        1: 'In transition/Will be back',
        2: 'No Longer Supported',
        3: 'Unknown/Author Disappeared',
        5: 'Now in Standard Distribution',
        8: 'Unknown/Dead Link',
        9: 'Dead and Gone',
    }

The only flag used so far is the "8" ... oh, and the "5" in the single
case of the old cPickle module. (And i think i may have accidentally
given a 9 flag where i meant 8 in a few cases... as i say, it's in
flux and a bit confusing. The above statuses (as now programmed)
only show up on the details page when it is non-zero. Not sure
how and where to use the rest... but i have created them in the
event that one day i get a flash of insight in this direction.

The *real* problem is figuring out when the heck something becomes
"unmaintained". Not a lot of authors announce that sort of thing. <g>

Perhaps there should be a time limit. It could even happen
automatically. If there is no update in x months the flag
automatically gets bumped to "unmaintained". But then this is probably
not accurate either, as sometimes people "maintain" old work for
quite a while... just don't actively develop it anymore, so perhaps
there should be a distinction there.

Of course there is always then just the "last updated" date in
my database. I had intended to impleemnt some filters at some point.
For example, so epople can, if they want, filter out everything more
than a year old, etc. Or more than a week old, if they insist. Heh.

I have been thinking about these issues especially lately as I've
been working through the /pub/python/contrib directories. I've added
(maintaining the file dates as 'last modified') already everything
from Database/ and DataStructures/ (which i later noticed was also
symlinked to Math/). There is a lot of really, really old junk in
there. Though there's also some really, really old nifty neato stuff
too. (-: (Some little obscure gems i had not noticed before---just
because it's old doesn't necessarily mean it's bad!)

But what to do about the old stuff which is obsolete. And i'm
especially bothered by the thought of old stuff which is so old that
it will not even work with python 1.5x ... i wish i had some way of
flagging that... to warn unsuspecting people.

On the other hand, there's not *that* much of the old stuff, so
perhaps it's not worth worrying about that much at this time.

If you know of any Abandoned/Unsupported code, let me know. I'll
update the flags ASAP!! (-:

> containing the actual code; Parnassus points to human-readable Web
> pages, not directly to the .tgz file, and it probably shouldn't have a

This has changed. I have added a second field. Now each item has "URL"
(intended to point always and only to human readable page---or ftp
directory), and also now a "download" field, which is intended to
point whenever possible to binary (or raw script) (though only a few
dozen items have this so far). So already i have moved, at least a
little, in this direction.

Again, this is a bit non-obvious to viewers... in that i only print on
the details page what is available. If there is no "download" link
defined then it simply does not show up, rather than saying "Not
Available", or whatever. But if there is a direct download link, it
shows up. If you do an URL search for "gz" for example, you'll notice
most if not all of them items will have "download" links now.

Also the submission form has the added field.

> pointer to it.  How does CPAN handle this?  Does it list foo-*.tgz and
> take the one where * is the highest version number?

CPAN lists everything last i checked (which was a long time ago!).
It's up to the user to decide what version they want (as if anyone
doesn't want the latest <G>)... but i'm far from expert (or even
slightly knowledgable) on the workings of CPAN.

...