[Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24

[Bob Ippolito]

On Dec 20, 2004, at 8:30 AM, Jon Schull wrote:

> For what its worth I came across a seemingly related set of issues 
> last night while trying to get apache to run python cgis.  Our 
> solution was to rewrite the #! lines as
> #! /sw/bin/env /sw/bin/python (the magic was in adding the first 
> phrase).  Related discusssion and alternative solutions is at  
> http://projects.edgewall.com/trac/wiki/TracOnOsx

Apache starts as root with root's default environment.  It's not going 
to have /sw/bin in its path, so /usr/bin/env python is not going to run 
Fink python.  You might as well replace it with #!/sw/bin/python.  Why 
the hell does Fink have its own env, anyway?

> Jon said
>>
>> The ideal would of course be a single python.  But failing that would 
>> be a single installer that would put in place the two (or even more) 
>> pythons needed in a manner that allowed one to work and install new 
>> modules as needed, without risking obscure disasters.

Darwinports Python and the vendor Python play together perfectly 
nicely, with no obscure disasters anywhere that I've seen.  If you are 
having conflicts between Fink and vendor Python, then it must be caused 
by Fink.  Probably due to the init script in your .bashrc / .tcshrc 
that sets up your environment in such a way that everything you do can 
end up using or linking to Fink-built stuff.  Darwinports doesn't have 
any such hacks, and never mangles your environment like that.

> Jack said
>> This is a known problem, which is explained in Mac/OSX/Dist/README:
>>> Currently (November 2003) there is still a bug in the build procedure
>>> for $DESTROOT builds: building some of the applets will fail (in
>>> ``Mac/OSX/Makefile``) if you don't have the same version of Python 
>>> installed
>>> normally. So before doing the distribution you should build and 
>>> install
>>> a framework Python in the normal way.
>>
>> Unfortunately, the problem is rather difficult to fix. buildapplet 
>> (or py2app, or similar tools) will need to be told that we're in a 
>> destroot install situation, so that if it wants filenames it should 
>> use the non-destrooted version but if it actually needs the data 
>> that's in the files it should use the destrooted filename.
>>
>> I can live with the current workaround for MacPython installers, if 
>> it's a problem for darwinports file a bugreport and a solution may be 
>> available sooner:-)
>
> Jon sighs...
> Unfortunate indeed.  You can live with it, and I don't even understand 
> your explanation. ;-/
>
> Its ironic that the python community values such elegance in the 
> language yet tolerates such complexity in context.  I presume  that's 
> because there's no alternative.

As Jack said, if you do things in the supported way, it just works.  
DESTROOT is only used in relatively strange situations like when 
building packages with Darwinports (probably Fink too).  Since Jack is 
the maintainer of Python, but not Fink or Darwinports Python, it's more 
or less YAGNI for him.  Given extremely limited time and resources, why 
solve a problem you don't have?

... and the DESTROOT thing isn't really relevant to the problems you 
brought up, anyway.  This particular limitation only matters if you are 
building a framework Python, and neither Fink nor Darwinports currently 
provide such a build.

-bob