Prev: This is the way i make my dream and monthly income
Next: What's the largest python/django powered website in the world?
From: Antoine Pitrou on 30 May 2010 15:55 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 30 May 2010 18:16 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 30 May 2010 18:11 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 30 May 2010 18:49
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 |