MySQLdb install vs. "setuptools"

[Benjamin Kaplan]

On Sun, May 30, 2010 at 3:16 PM, John Nagle <nagle at animats.com> wrote:

> Antoine Pitrou wrote:
>
>> On Sun, 30 May 2010 10:10:00 -0700
>> John Nagle <nagle at animats.com> wrote:
>>
>>>     Actually, a "built" but "uninstalled" Python works fine.
>>>  If it
>>> didn't, "make test" wouldn't work.
>>>
>>
>> That's a completely unrelated thing. The main reason "make test" works
>> with an uninstalled Python is simply so that the core developers' life
>> is easier. It doesn't mean all Python functionalities work in that
>> context.
>>
> >
>
>>     On the other hand, options to "./configure" apparently don't work
>>> right in Python 2.6 through 3.x.  "--libdir" and "--bindir" don't
>>> actually
>>> do anything.
>>>
>>
>> You can use "--prefix" instead, it works.
>>
>
>    It's nice that some of the options work.  Note that someone who
> used "--bindir", expecting it to work, might end up overwriting their
> existing Python installation unintentionally, which would break system
> administration tools like cPanel and "yum".
>
>    cPanel support recommends against installing a new Python other
> than through "yum".
>
>
> http://forums.cpanel.net/f5/mailman-breaks-stable-upcp-due-python-upgrade-126453.html
> http://forums.cpanel.net/f5/upgrade-python-whm-113593.html
>
>    They don't trust other install mechanisms.  With good cause.
>
>      The real problem here remains the unnecessary use of "setuptools".
>>>
>>
>> No, again, the real problem is just that you are trying to install
>> modules for an uninstalled Python.
>> You may hate setuptools with a passion, but it's unconstructive and
>> useless to put the blame on it without any solid argument.
>> Do yourself a favour: pass the proper options to "./configure", and
>> install Python.
>>
>> Regardssetu
>>
>> Antoine.
>>
>
>   Having demonstrated in a previous post that 1) the use of "setuptools"
> was completely unnecessary, and 2) it's quite possible to load and use
> MySQLdb in an "uninstalled" Python, we can dismiss the above argument.
>
>   The ongoing low quality of Python distribution mechanisms, and the
> denial of that fact, is a major part of why Python, after 20 years, is far
> less available than Perl.  The latest production versions of Red Hat
> Enterprise Linux and CentOS, the major server distributions, still ship
> with Python 2.4.3, a five year old version of Python.
>
>                                        John Nagle
>
>
Based on a quick search, CentOS 5.5 ships with Perl 5.8.8. I would assume
that it uses the same version as RHEL. Based on another quick search, Perl
5.8.8 shipped in February 2006, one month before Python 2.4.3.

What does this have to do with distribution mechanisms again?

And last time I checked, Python is now preinstalled on every OS worth
speaking of except for Windows. Last time I checked, Perl was preinstalled
on every OS worth speaking of except for Windows. With IronPython putting
Python on the .NET Framework, one could argue that, if anything, Python is
more available than Perl. Particularly if Microsoft ever gets around to
giving IronPython and IronRuby first class status in Visual Studio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100530/f2f9f35d/attachment-0001.html>