I think I need more detail in the build directory
Folks,
I think I need more details in the filenames (the temp. and lib. ones)
in the build directory.
On MacOSX there are two ways to build Python: in the traditional unix
way (statically linked, prefix is usually /usr or /usr/local) or in the
all-singing-all-dancing framework way (dynamically linked with extra
bells and whistles, the python installation deep down in
/Library/Frameworks/Python.framework/etcetcetc, with a symlink "python"
usually in /usr/local/bin). Extension modules for these two Pythons are
incompatible, but unfortunately they don't realise that, and things may
even sort-of work some of the time.
Note that this problem has really existed all along, and on all
platforms (try building a module with a refcount-debug python, and then
doing a setup install with a non-refcount-debug python for a nasty
surprise), but for MacOSX it may now become an end-user problem, since
Apple ships Python in Jaguar and this is a static python, but to get
access to the MacPython goodies people will download a source
distribution and build a framework python.
I have an idea on a solution to this, but I'm not sure whether it's
feasible (and correct:-):
1. Encode features that make a python interpreter and a module
incompatible in PYTHON_API_VERSION. We have about 20 bits left in
there. This would however require convincing the core developers.
2. Use PYTHON_API_VERSION in stead of the "2.3" style version in the
distutils filenames.
Comments?
--
- Jack Jansen
Jack Jansen wrote:
Folks, I think I need more details in the filenames (the temp. and lib. ones) in the build directory.
On MacOSX there are two ways to build Python: in the traditional unix way (statically linked, prefix is usually /usr or /usr/local) or in the all-singing-all-dancing framework way (dynamically linked with extra bells and whistles, the python installation deep down in /Library/Frameworks/Python.framework/etcetcetc, with a symlink "python" usually in /usr/local/bin). Extension modules for these two Pythons are incompatible, but unfortunately they don't realise that, and things may even sort-of work some of the time.
Note that this problem has really existed all along, and on all platforms (try building a module with a refcount-debug python, and then doing a setup install with a non-refcount-debug python for a nasty surprise), but for MacOSX it may now become an end-user problem, since Apple ships Python in Jaguar and this is a static python, but to get access to the MacPython goodies people will download a source distribution and build a framework python.
I have an idea on a solution to this, but I'm not sure whether it's feasible (and correct:-): 1. Encode features that make a python interpreter and a module incompatible in PYTHON_API_VERSION. We have about 20 bits left in there. This would however require convincing the core developers. 2. Use PYTHON_API_VERSION in stead of the "2.3" style version in the distutils filenames.
Rather than trying to be clever here, why not add an option to distutils to let the packager add an arbitrary directory name extension to the build dir ?! That way, the developer can add whatever information is needed to the build dir name. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
On zondag, nov 17, 2002, at 23:06 Europe/Amsterdam, M.-A. Lemburg wrote:
Jack Jansen wrote:
Folks, I think I need more details in the filenames (the temp. and lib. ones) in the build directory. On MacOSX there are two ways to build Python: in the traditional unix way (statically linked, prefix is usually /usr or /usr/local) or in the all-singing-all-dancing framework way (dynamically linked with extra bells and whistles, the python installation deep down in /Library/Frameworks/Python.framework/etcetcetc, with a symlink "python" usually in /usr/local/bin). Extension modules for these two Pythons are incompatible, but unfortunately they don't realise that, and things may even sort-of work some of the time. Note that this problem has really existed all along, and on all platforms (try building a module with a refcount-debug python, and then doing a setup install with a non-refcount-debug python for a nasty surprise), but for MacOSX it may now become an end-user problem, since Apple ships Python in Jaguar and this is a static python, but to get access to the MacPython goodies people will download a source distribution and build a framework python. I have an idea on a solution to this, but I'm not sure whether it's feasible (and correct:-): 1. Encode features that make a python interpreter and a module incompatible in PYTHON_API_VERSION. We have about 20 bits left in there. This would however require convincing the core developers. 2. Use PYTHON_API_VERSION in stead of the "2.3" style version in the distutils filenames.
Rather than trying to be clever here, why not add an option to distutils to let the packager add an arbitrary directory name extension to the build dir ?!
You miss the point. The problem is not with specific packages, the
problem is general. The directory names within "build" are supposed to
be encoded in such a way that you can do "python setup.py build" with
two different pythons and the files created for the two pythons won't
conflict.
As it is now this works fine if the two pythons differ in version
number or if the two pythons are for different platforms. It does not
work, however, if the two pythons are the same version and run on the
same platform, but differ in another incompatible way.
--
- Jack Jansen
Jack Jansen wrote:
On zondag, nov 17, 2002, at 23:06 Europe/Amsterdam, M.-A. Lemburg wrote:
Rather than trying to be clever here, why not add an option to distutils to let the packager add an arbitrary directory name extension to the build dir ?!
You miss the point. The problem is not with specific packages, the problem is general. The directory names within "build" are supposed to be encoded in such a way that you can do "python setup.py build" with two different pythons and the files created for the two pythons won't conflict.
As it is now this works fine if the two pythons differ in version number or if the two pythons are for different platforms. It does not work, however, if the two pythons are the same version and run on the same platform, but differ in another incompatible way.
And that's what you could put to work by specifying an option which let's you introduce extra dir-name components, e.g. --build-dir-addon pydebug-nounicode could generate: temp.linux-i686-2.1.pydebug-nounicode/ as temporary build dir. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
On Mon, Nov 18, 2002 at 03:30:05PM +0100, Jack Jansen wrote:
As it is now this works fine if the two pythons differ in version number or if the two pythons are for different platforms. It does not work, however, if the two pythons are the same version and run on the same platform, but differ in another incompatible way.
I'd have no objection to using API_VERSION instead of the Python version, but it only became available to Python code in 2.3CVS, so there'd be no way to get it in Apple's Python. Similar problems apply to tracing/debugging; can Python code determine what the options are for the interpreter it's running in? --amk (www.amk.ca) MALCOLM: Angels are bright still, though the brightest fell. -- _Macbeth_, IV, iii
participants (3)
-
Andrew Kuchling
-
Jack Jansen
-
M.-A. Lemburg