unusual platform-dependent problem with tarfile created by setuptools
hey all - the MyghtyUtils package, version 0.52 on cheeseshop, has this general file structure: MyghtyUtils-0.52/setup.py MyghtyUtils-0.52/ez_setup.py MyghtyUtils-0.52/lib/myghtyutils/__init__.py MyghtyUtils-0.52/lib/myghtyutils/memcached.py MyghtyUtils-0.52/lib/myghtyutils/<other .py files> MyghtyUtils-0.52/test/Container.py MyghtyUtils-0.52/test/LRUCache.py MyghtyUtils-0.52/test/SyncDict.py MyghtyUtils-0.52/test/testbase.py however, when you run "python setup.py sdist" on an OS X machine (interestingly, *not* on a windows machine), the resulting tar/gz file contains an extra file: MyghtyUtils-0.52/test/._Container.py no idea why that is...but this creates problems on windows. Then, when you go to install this package on a windows machine (*not* on an OS X or other unixy machine), you get this error: File "c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools \archive_util.py", line 192, in unpack_tarfile tarobj._extract_member(member,dst) # XXX Ugh File "C:\Python24\lib\tarfile.py", line 1440, in _extract_member self.utime(tarinfo, targetpath) File "C:\Python24\lib\tarfile.py", line 1572, in utime raise ExtractError, "could not change modification time" tarfile.ExtractError: could not change modification time when I go into tarfile.py line 1572 and modify the exception to also print out the underying error, you get this: IOError: [Errno 13] Permission Denied: 'MyghtyUtils-0.52\\test\ \._Container.py' So the extra "._Container.py" file is the source of the windows issue. If you want to reproduce, simply check out the latest source of MyghtyUtils from http://svn.myghty.org/myghtyutils/trunk and run "setup.py sdist". I havent seen this happen with my other packages. I have solved the problem by just running the sdist on the windows machine. but this is pretty strange. any ideas ?
On Jul 28, 2006, at 2:36 AM, Michael Bayer wrote:
MyghtyUtils-0.52/test/testbase.py
however, when you run "python setup.py sdist" on an OS X machine (interestingly, *not* on a windows machine), the resulting tar/gz file contains an extra file:
MyghtyUtils-0.52/test/._Container.py
no idea why that is...but this creates problems on windows.
test/Container.py contains a resource-fork or some other mac-specific attribute. At least in plain distutils 'sdist' seems to the platform tar and on OSX that creates ._* files for mac-specific attributes/ resource-forks. Ronald
mac specific ? i dont think so. however, perhaps something in the file is being incorrectly construed as mac-specific (but still, I dont think so). heres the code: http://www.myghty.org/trac/browser/myghtyutils/trunk/test/Container.py and the full set of imports... from myghtyutils.container import * import myghtyutils.buffer as buffer import random, time, weakref, sys, re import testbase import unittest, sys try: import thread except: raise "this test requires a thread-enabled python" and from then on its just unit tests. Ill see if just having a file called "Container.py" with minimal python in it produces the same results (not at an appropriate workstation at the moment). Ronald Oussoren wrote:
On Jul 28, 2006, at 2:36 AM, Michael Bayer wrote:
MyghtyUtils-0.52/test/testbase.py
however, when you run "python setup.py sdist" on an OS X machine (interestingly, *not* on a windows machine), the resulting tar/gz file contains an extra file:
MyghtyUtils-0.52/test/._Container.py
no idea why that is...but this creates problems on windows.
test/Container.py contains a resource-fork or some other mac-specific attribute. At least in plain distutils 'sdist' seems to the platform tar and on OSX that creates ._* files for mac-specific attributes/ resource-forks.
Ronald
On Jul 29, 2006, at 6:31 AM, Michael Bayer wrote:
mac specific ? i dont think so. however, perhaps something in the file is being incorrectly construed as mac-specific (but still, I dont think so).
heres the code:
That's not relevant, that is the data fork of the file. The file has some non-posix attributes (such as the attribute that gets set when you set the 'Locked' flag in the 'Get Info' screen info the Finder), or a resource fork (maybe it has a custom Icon). I can't tell which without actually seeing the data. Feel free to sent me the output of sdist on the mac and I'll have a look. Ronald
sorry, I wasnt familiar with the term "resource fork" or its specifics until now, post-wiki/googling. so yes this is exactly the issue. quickest way to whack it, short of downloading all kinds of resource-fork-management tools (theres also a bunch that come with xcode but i cant get them to do anything useful...such as DeRez which just says the resource fork is "empty and unitialized"...why is that?), seems to be just cat the text of the file so some other file, delete the original, then rename; then youre just left with the data fork and that seems to clean it up. thanks very much. Ronald Oussoren wrote:
On Jul 29, 2006, at 6:31 AM, Michael Bayer wrote:
mac specific ? i dont think so. however, perhaps something in the file is being incorrectly construed as mac-specific (but still, I dont think so).
heres the code:
That's not relevant, that is the data fork of the file. The file has some non-posix attributes (such as the attribute that gets set when you set the 'Locked' flag in the 'Get Info' screen info the Finder), or a resource fork (maybe it has a custom Icon).
I can't tell which without actually seeing the data. Feel free to sent me the output of sdist on the mac and I'll have a look.
Ronald
participants (2)
-
Michael Bayer -
Ronald Oussoren