From: Antoine Pitrou on
On Sun, 30 May 2010 10:10:00 -0700
John Nagle <nagle(a)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.

> 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.

Regards

Antoine.


From: John Nagle on
Antoine Pitrou wrote:
> On Sun, 30 May 2010 10:10:00 -0700
> John Nagle <nagle(a)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
From: Antoine Pitrou on
On Sun, 30 May 2010 15:16:42 -0700
John Nagle <nagle(a)animats.com> wrote:
>
> 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".

Well, usually you don't type "sudo" unintentionally...

> 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.

"Far less available"? How so?

> 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.

And of course nothing in this is Python's or setuptools' fault, since
it's just Redhat's policy, so I wonder what you're trying to tell us.

(not to mention that it doesn't have anything to do with the original
topic anymore, either)


From: David Cournapeau on
On Mon, May 31, 2010 at 7:16 AM, John Nagle <nagle(a)animats.com> wrote:

>    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.

This has absolutely nothing to do with how python is installed. It is
common sense that you should upgrade an installed package through the
package manager mechanism (here yum), and is true for any software,
python or not.

> 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.

Yes, by definition RHEL ships softwares that does not change for a
long time. By your argument, the linux kernel and gcc are broken
because they are 4 years old on RHEL 5 (linux 2.6.18. gcc 4.0.*). That
does not make any sense.

cheers,

David