[Distutils] RE: [Crew] Wizards' Resolution to Zope/PIL/mxDateTime conflict?

[Jeffrey C. Jacobs]

> -----Original Message-----
> From:	Tom Bryan [SMTP:tbryan@server.python.net]
> Sent:	June 17, 1999 12:19 PM
> To:	Crew List
> Subject:	Re: [Crew] Wizards' Resolution to Zope/PIL/mxDateTime
> conflict?
> 
> Perhaps this discussion should be moved to the PSA list or to the
> comp.lang.python newsgroup.  The Starship isn't going to be the only
> computer with this problem.  We juat are going to be one of the few
> machines that currently has *many* third-party extensions to Python.  As
> Python grows in popularity, this problem is only going to get worse.  In
> the worst case scenario, people won't be able to use a Python solution
> because the required third-party extensions conflict and they don't want
> to kludge it all together themselves.
> 
		It seems to me perhaps the simplest solution is, dare I say
it, Bureaucracy!  Okay, now that I got you all riled up, let me explain.
Right now, anyone can go write a Python package and post it up all over the
place, helter-skelter.  It may even appear on www.python.org.  However, if
I'm writing Package A and you have written package B unbeknownst to me, I
might be stepping on your toes.  That is to say, if my package does the same
thing, so what? more choice to the hacker.  The problem is when I CALL my
module/package the same thing as you.  It is this naming convention that
needs to be cleaned up, as I see it.  Rather than come up with some complex
scheme of installation or some major changes to the python language,
wouldn't it just be simpler to standardize our naming now, before Python
does reach the 10,000,000 user mark?  That is, rather then trying to come up
with an installation-level solution, why not just have someone review all
packages for conflicts on a first-come-first-serve basis?  Set up a
committee of Python certification which will basically go through each new
package and install it on a max-install station.  If there are no conflicts,
the package is certified and the author gets official recognition.  If there
is conflict, a polite e-mail can be sent to the author suggesting he or she
modify / change the name(s) chosen for his or her package to avoid future
conflict potential.
		As for currently existing conflicts, there is of course the
problem with install-base.  The best thing I can suggest is a renaming of 1
or more existing packages to conform to the Python standard extension model.
That is to say, there would then be two copies of the package available -- 1
with backwards-compatible naming and 1 which is the Python-certified name.
Based on the desire of the package author / maintainer, the old names could
be phased out as time goes by in new releases.  Typically, the more
ingrained a package is in an application, the less likely it is that a
conflicting package will be installed on that system.  Thus *hopefully* this
should not effect any previous install of Python.  It would probably be best
when conflicts *do* occur to ask *both* pre-existing Package authors to try
to come up with new names, so as to be more even-handed, though I'd suggest
larger packages get priority.
		The best thing is, when Microsoft starts to see Python as a
threat to its Visual xxx monopoly and starts to "embrace" Python with their
new Visual P++ integrated development environment, and starts adding weird
packages left, right and center, the Python certification committee can just
"uncertify" the extensions and (hopefully) prevent the destruction of the
language the same way they did Java.  I think Mark Hammond would be heading
Microsoft off at the pass, as it were WRT this issue though.
		What's more, we here at Starship seem to be the perfect
candidate to be the "Python Package" machine, at least on the Unix / Linux
side -- I should hope a similar all-install machine could be set up for
Microsoft-based system verification, as well as Mac and any other OS which
has a unique package list.

> Does someone want to make an intelligent, concise post to one of the other
> forums?  comp.lang.python has enough posters who want to "improve" the
> language.  Perhaps we could direct their energy into a useful change.
> 
	I am sending a copy of this over there...

			Be Seeing You,

			Jeffrey.