Compiling/Installing Python 2.7 on OSX 10.6

[Ned Deily]

In article <6F087CE1-5391-4EE3-B92A-5A499FDF0E6C at semanchuk.com>,
 Philip Semanchuk <philip at semanchuk.com> wrote:
> You might want to try this before running tar to see if it inhibits the ._ 
> files:
> export COPYFILE_DISABLE=True
> 
> 
> I know that tells tar to ignore those files (resource forks, no?) when 
> building a tarball. I don't know if it helps with extraction though.

Interesting.  It's been so long since I've had to deal with ._ 's (which 
is where metadata for extended attributes including resource forks are 
stored), I had forgotten about that poorly documented option for 10.5 
and 10.6.

A little experiment: from OS X 10.6, I NFS-mount a remote Linux (ext3) 
file system and have created files on it with extended attributes.  
Using ls on either the OS X or the Linux side, the ._ files appear as 
regular files.  On the Linux side,  I use gnu tar to archive the files 
and move that archive back to OS X.  If I then use the stock Apple 10.6 
tar to extract that archive to an HFS+ directory, the extended 
attributes are by default restored properly (they can be viewed with ls 
-l@) and no '._' files - great!  If I first export 
COPYFILE_DISABLE=True, then the tar extraction appears to ignore the ._ 
files: the extended attributes are not set and the ._ files still do not 
appear.

So the COPYFILE_DISABLE trick may very well work for this issue.  It 
still raises the question of why the ._ files are being created in the 
first place.  They shouldn't be on the python.org tarball so it would 
seem most likely they are due to some operation on the OS X machine that 
causes extended attributes to be created.  Nothing wrong with that, just 
kind of interesting.

-- 
 Ned Deily,
 nad at acm.org