[Python-Dev] PEP 370, open questions (original) (raw)

Ronald Oussoren ronaldoussoren at mac.com
Thu Jan 17 16:47:38 CET 2008

On 17 Jan, 2008, at 14:22, glyph at divmod.com wrote:

On 12:02 pm, ronaldoussoren at mac.com wrote:

On 17 Jan, 2008, at 9:40, glyph at divmod.com wrote:

On 07:55 am, lists at cheimes.de wrote: The framework build of Python definitly targets the upper layer of the OSX stack, not just the Unix core. This sometimes causes confusion, but mostly from developers wandering over from a Linux system that complain that OSX isn't Linux. The framework build targets both layers, as I understand it - and it sounds like you're saying it too, since it's not "just" the UNIX core. Solaris isn't Linux either, by the way. These conventions hold across far more than one operating system :).

I know, but somehow most people I run into that even know that there
are more unix flavors than Linux also know that while all unices are
simular they are not exactly the same.

Note that even Darwin is not Linux, there are several differences that cause problems for naive porters. Two of those: Darwin uses different binary formats for shared libraries and plugins; the darwin linker hardcodes the full path to shared libraries into executables (without a runtime search path). Distutils should take care of this distinction in Python's case, no? Xxx's autotools generate a shared library, PyXxx's setup.py generates a plugin (or "dylib", is that still what they're called these days?).

Distutils does take care of it, but that doesn't stop users from
complaining that 'cc -shared' doesn't result in a workable python
extension ;-).

BTW. dylibs are shared libraries, there is no common suffix for
bundles. Python uses '.so' for its bundle, adding to the confusion for
folks used to systems using ELF libraries ;-)

An example: Let's say you have a GNU autotools project in C, which we'll call "Xxx", and a set of Python bindings, PyXxx. Combinator deals with this by using ~/.local, and providing scripts to set up PATH and LDLIBRARYPATH to point to ~/.local/bin and ~/.local/lib, respectively. ~/Library/Combinator would be a better installation root on OSX, that location fits better into guidelines from Apple and also avoids completely hiding the Combinator data from the user. I disagree, but Combinator's a complex beast and has a lot of other moving parts which need to live in specific places. Its main purpose is to manage your import path to easily switch between different development branches of multiple projects, and so most of its data is already in locations that the user has specified. A key thing about ~/.local in this case is that it isn't specific to Combinator. It's any per-user installed dependency libraries for development purposes, not necessarily on Combinator-managed projects, and not even necessarily Python projects.

Ah, so ~/.local is "just" a per-user variation on /usr/local? I didn't
even know of that convention before this thread started, I tend to use
~/local (without dot) instead.

Why? Just because users can't remember on which platform they are developing ;-)? That said, there's a libpython.a file in the framework build for basicly that reason: enough users complained about there not being a python library they could link to that it was easier to add a symlink then trying to educate everyone. The system installation of Python on the mac has a nod in this direction as well. /usr/bin/python is also present, as is /usr/lib/ pythonX.Yÿ0Cas symlinks between the two locations. You could teach Combinator about running configure scripts ;-). Better yet, perhaps somebody should teach configure about MacOS, and about per-user installation ;).

I value my life to much to even think about developing this feature
for auto*.

Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20080117/e6f94a44/attachment.bin

More information about the Python-Dev mailing list