[Python-Dev] PEP 370, open questions

[Ronald Oussoren]

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