Configure option to change Python's name?
This idea is only half-baked, so please fire away, or tell me to go ahead, or go hide under a stone. I would like a configure option that changes the name of "python" everywhere: in the executable, in the dynamic library name, the MacOSX framework name, etc. This would allow you to have two Pythons on a system that are completely 100% independent of each other. The idea was triggered by Michael Hudson, who wanted to install a debugging-enabled framework build of Python on MacOSX, which shouldn't interfere with the normal Python (either Apple-installed or user-installed). It turns out this is doable through meticulous hacking of the Makefile after configure (and, for now, ignoring the few hardcoded "Python.framework" references in Lib, but those need fixing anyway). For other unix systems a similar approach would work to isolate a debug-python from the normal production python. But then I thought of another use: this would allow you to have a MacPython 2.3.3 distribution as well as the Apple-installed 2.3 distribution without any interference possible. And there are probably similar uses on other platforms. -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
On Jan 21, 2004, at 11:08 AM, Jack Jansen wrote:
This idea is only half-baked, so please fire away, or tell me to go ahead, or go hide under a stone.
I would like a configure option that changes the name of "python" everywhere: in the executable, in the dynamic library name, the MacOSX framework name, etc. This would allow you to have two Pythons on a system that are completely 100% independent of each other.
The idea was triggered by Michael Hudson, who wanted to install a debugging-enabled framework build of Python on MacOSX, which shouldn't interfere with the normal Python (either Apple-installed or user-installed). It turns out this is doable through meticulous hacking of the Makefile after configure (and, for now, ignoring the few hardcoded "Python.framework" references in Lib, but those need fixing anyway). For other unix systems a similar approach would work to isolate a debug-python from the normal production python.
But then I thought of another use: this would allow you to have a MacPython 2.3.3 distribution as well as the Apple-installed 2.3 distribution without any interference possible. And there are probably similar uses on other platforms.
I'm +100000 on this; it's good for MacPython, python-dev'ers, and it would also help forks like stackless. -bob
Jack Jansen wrote:
The idea was triggered by Michael Hudson, who wanted to install a debugging-enabled framework build of Python on MacOSX, which shouldn't interfere with the normal Python (either Apple-installed or user-installed). It turns out this is doable through meticulous hacking of the Makefile after configure (and, for now, ignoring the few hardcoded "Python.framework" references in Lib, but those need fixing anyway). For other unix systems a similar approach would work to isolate a debug-python from the normal production python.
Why can't you configure with an entirely different --prefix, such as /just/for/me? Regards, Martin
On Wed, Jan 21, 2004, "Martin v. Löwis" wrote:
Jack Jansen wrote:
The idea was triggered by Michael Hudson, who wanted to install a debugging-enabled framework build of Python on MacOSX, which shouldn't interfere with the normal Python (either Apple-installed or user-installed). It turns out this is doable through meticulous hacking of the Makefile after configure (and, for now, ignoring the few hardcoded "Python.framework" references in Lib, but those need fixing anyway). For other unix systems a similar approach would work to isolate a debug-python from the normal production python.
Why can't you configure with an entirely different --prefix, such as /just/for/me?
That only works if you want to provide the full path to the executable each time you use it (or if you are willing to set up a link or alias that sits in the PATH that does what Jack suggests). I'm somewhere between +0 and +1; the former is because I worry a bit about dealing with people who do this when they don't know what they're doing. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ A: No. Q: Is top-posting okay?
Aahz wrote:
Why can't you configure with an entirely different --prefix, such as /just/for/me?
That only works if you want to provide the full path to the executable each time you use it (or if you are willing to set up a link or alias that sits in the PATH that does what Jack suggests).
Right. I see no problems with creating symlinks, though.
I'm somewhere between +0 and +1; the former is because I worry a bit about dealing with people who do this when they don't know what they're doing.
I'm more concerned with the maintenance burden that the feature adds. There are many places that need attention, those places become unreadable after the change, it will take ages to discover them all, and the feature will break every few weaks when a new such place is added. Regards, Martin
"Martin v. Löwis" <martin@v.loewis.de> writes:
Jack Jansen wrote:
The idea was triggered by Michael Hudson, who wanted to install a debugging-enabled framework build of Python on MacOSX, which shouldn't interfere with the normal Python (either Apple-installed or user-installed). It turns out this is doable through meticulous hacking of the Makefile after configure (and, for now, ignoring the few hardcoded "Python.framework" references in Lib, but those need fixing anyway). For other unix systems a similar approach would work to isolate a debug-python from the normal production python.
Why can't you configure with an entirely different --prefix, such as /just/for/me?
I think this would be tricky on OS X, which looks for frameworks in fixed places. It really would be nice to have the framework have a different name. But this may be an OS specific problem. Cheers, mwh -- ... so the notion that it is meaningful to pass pointers to memory objects into which any random function may write random values without having a clue where they point, has _not_ been debunked as the sheer idiocy it really is. -- Erik Naggum, comp.lang.lisp
Jack Jansen <Jack.Jansen@cwi.nl> writes:
This idea is only half-baked, so please fire away, or tell me to go ahead, or go hide under a stone.
I would like a configure option that changes the name of "python" everywhere: in the executable, in the dynamic library name, the MacOSX framework name, etc. This would allow you to have two Pythons on a system that are completely 100% independent of each other.
The idea was triggered by Michael Hudson, who wanted to install a debugging-enabled framework build of Python on MacOSX, which shouldn't interfere with the normal Python (either Apple-installed or user-installed). It turns out this is doable through meticulous hacking of the Makefile after configure (and, for now, ignoring the few hardcoded "Python.framework" references in Lib, but those need fixing anyway).
Can I take this to mean that you got it to work? I've given up for the moment on the grounds that I wanted a working Python install... I like the idea, but I'm not sure it has applicability outside MacOS X. I have some configure hacks that change the name of the framework if you combine --enable-framework and --with-pydebug, but haven't put them to the test fullly yet. Cheers, mwh -- Python enjoys making tradeoffs that drive *someone* crazy <wink>. -- Tim Peters, comp.lang.python
participants (5)
-
"Martin v. Löwis" -
Aahz -
Bob Ippolito -
Jack Jansen -
Michael Hudson