[Pythonmac-SIG] Python bindings for DB XML

[Bob Ippolito]

On Jan 26, 2004, at 2:27 PM, Chris Barker wrote:

> Bob Ippolito wrote:
>> On Jan 26, 2004, at 12:17 PM, Chris Barker wrote:
>>>    #!/usr/bin/env pythonX.X
>>>
>>> At the top of your file. Where X.X is the version of Python you want 
>>> (python2.2, python2.3, etc.)
>
>> I agree with you, to a small extent, but this pythonX.X business that 
>> you propose only matters to OS X 10.2 users.  On 10.2, any way you 
>> slice it, /usr/local/bin isn't in the default path anyways
>
> In theory, /usr/local/bin will never have vendor installed software, 
> but I'm not so sure that I ALWAYS want a "local" version of a given 
> program to be the default.

More often than not, you do.  I would use shell aliases to point to 
/usr/bin if I wanted to (I don't have any yet).

>> (if I remember correctly), so the PATH thing is generally reasonable 
>> (especially because Apple didn't use Python at all on 10.2.x).
>
> I'm really looking to the future here. no python version less than 
> 10.2 has ever been an issue on OS-X. IF you look at the Redhat story, 
> however, they built some tools on Python 1.5, and saw no reason to 
> upgrade for quite few years (until RedHat 8, with Python2.2). If 
> RedHat had just had the brains to put #!/usr/bin/python1.5 in their 
> files there never would have been a problem. Instead, all of us RedHat 
> users have to do it, which I think we should anyway.

Yeah, I had that problem too.

> Apple may very well decide to keep using Python 2.3 when Python 3.5 is 
> out. We have no way of predicting that, and we should not count on 
> them doing anything in particular.

I'm not too worried about that.

>> In any case, there's one tiny little problem with what you propose: 
>> It doesn't do a damn thing for 10.3 users.
>
> It might when 2.4 (or whatever) comes out.
>
>>     - can't accommodate for minor versions (f.ex Apple Python 2.3.0 
>> and your own Python 2.3.3)
>
> I suppose you could put python2.3.3 on your #! line. In theory, this 
> shouldn't be neccesary, as minor versions are supposed to be 
> compataible. If only Apple would eiother upgrade Pythonl, or rrelease 
> the source to their extensions so we could upgrade it (they haven't 
> doen that have they?)

The python installation process doesn't use the minor version for 
install names.

> I would argue that Apple should do what RedHat should have done: put 
> an explicit path to the python they want in their scripts that use 
> python, including a minor version number. As they distribute both the 
> python version and all the scripts that use it, they could do that, 
> and it would solve a whole slew of problems. Of course, we have no 
> control over what apple does so we'll just have to live with what they 
> come up with. I don't have 10.3 installed yet...what do they put in 
> theie #! lines?

Apple uses /usr/bin/python - I don't see any reason to complain about 
that.  In any case, there is only ONE Apple-written Python script on an 
OS X 10.3 system: /usr/libexec/fax/coverpage.py.  Though a few other 
CoreGraphics-using scripts are in /Developer/Examples/Quartz/Python/ if 
you have Xcode installed.

>>     - can't accommodate build parameters debug build vs normal build
>
> I'd say don't put a debug build on your path at all...you should only 
> use that if you know you want it, i.e. use an explicit path

Well, sure.  I'll agree with that.

>>     - can't accommodate "distribution mechanism" (fink vs vendor vs 
>> user Python)
>
> This can be accomidated with an explicit path as well. As I think 
> about it, perhaps OS-X is uniform enough that you could just use 
> explicit paths all the time. On Linux, all the distros (and individual 
> installations) are different enough that you're much better off using:
>
> #!/usr/bin/env, and letting the system find the executable for you.
>
> That may not be the case on OS-X

I think /usr/bin/env is going to universally find fink if you have 
their shell script running.. I'm pretty sure /sw/bin goes before 
/usr/local/bin and wherever else.  I dunno, there's arguments to be 
made either way.  #!/usr/bin/env is certainly not the right solution if 
you depend on non-standard extensions.

>> People who are getting version mismatch problems are on 10.3, not 
>> 10.2. If you compiled an extension with Apple Python 2.2.0 on OS X 
>> 10.2, there's almost no way that you could accidentally load it from 
>> Python 2.3.x, and vice versa.  That is certainly not true if you have 
>> a user installation of Python on OS X 10.3.
>
> This entangling of different 2.3 pythons is way beyond me to 
> comprehend. There really should be a way to get the right libraries 
> once you get the right executable. It's certainly beyond the users 
> realm to figure this out for each python program written. I don't 
> think this is a problem on Linux, but then I'm not sure I've ever 
> tried it either.
>
> Bob, do you have any other suggestions?

The entangling of different 2.3 pythons is really all people have a 
problem with right now.. so far I've seen people have problems with:
	Apple Python 2.3 vs Fink Python (or fink libraries/compliers in 
general)
	Apple Python 2.3 vs Jaguar Python 2.3 ("oops, I meant to get the 
panther addons", vestige from 10.2, or didn't know better)
	Apple Python 2.3 vs User-Built 2.3.x (2.3.x fixes a bug that I need 
fixed, "I'm a python-dev'er")

I think the biggest problem is that /Library/Python/2.3/ (or the user 
equiv) is used by any framework built Python 2.3.x.  Bundles built for 
one are NOT going to necessarily be compatible with another (by 
default, they will most certainly NOT be compatible, because the load 
command in their mach-o header will point to the wrong framework).  
This problem in particular might be "solvable" by using -bundle_loader 
$PYTHON_EXECUTABLE instead of -framework Python when building bundles 
-- because in that case all you have to worry about is if their APIs 
are compatible not if they were built against the same build.  I am not 
entirely sure if this works though, because the linker might not like 
the fact that all the required symbols are actually coming from dylibs, 
not the executable itself.  I will have to try it.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040126/05812d01/smime-0001.bin