I'm using python 2.7/setuptools 3.6 to build an egg of my code (checked into perforce) using my setup.py. This egg gets installed into a virtualenv.
On osx/darwin this works fine.
On windows, the bdist creates scripts and data whose permissions are read-only (attrib+r), and they cannot overwrite themselves in a subsequent build of that egg. Similarly, >re-installing a new egg using virtualenv fails because the installed egg's scripts and data are not writable.
I thought it might be that when checked out from perforce, the permissions stayed read-only during the build of the egg, so I set all the files in my module to be read-write before building. Even when the original source files' permissions are all set to read-write, the generated bdist egg script/data content end up becoming read-only.
Yes, the default copy_file implementation from distutils keeps attributes on copy (preserve_mode parameter is non zero). In our setup.py we monkey patch the copy_file to get around this situation
Couple of questions.
- Since it works fine on osx, it seems like a bug in the windows implementation of setuptools. Is this known behavior, is there a reason for setting this on scripts/data on windows?
This is not a setuptools problem, but a (probably wrong) choice of defaults in distutils
- Is there a hook in the bdist egg build process I can use to set the attributes of the files correctly when the bdist egg is made? How/where should I define this in my setup.py?
In your setup.py, use a monkey patch like the one below:
#monkey-patch the copy_file function beacause it has the wrong default value for preserve_mode from distutils.file_util import copy_file as old_copy_file def non_preserve_copy_file(src, dst, preserve_mode=0, preserve_times=1, update=0, link=None, verbose=1, dry_run=0): return old_copy_file(src, dst, preserve_mode=0, preserve_times=preserve_times, update=update, link=link, verbose=verbose, dry_run=dry_run)
distutils.file_util.__dict__['copy_file'] = non_preserve_copy_file #end monkey patching