On Wed, Dec 24, 2008 at 12:12:07PM -0600, Tom Mueller (pkg-discuss) wrote: > I've noticed that when the same .py file is compiled to a .pyc file by > two builds, you don't get the same .pyc file.
Right. There's a timestamp embedded in the .pyc file corresponding to the time it was "compiled", as well as the path to the corresponding .py file. We've stabilized the pathname (it used to be local to the workspace it was built in), but there's nothing we can do about the timestamp, short of adding patches to Python. We've eliminated the worst side effect of the issue -- that the .pyc files are recompiled by the first user with sufficient permissions to write the files -- by putting timestamps in the actions of the .py files, so that Python doesn't think the .pyc files are out of date and try to recompile them. But yes, the .pyc files do get redelivered. The right answer for this is to write a content-hashing function for these, just like we do for ELF files, but this hasn't been done yet, since the expected savings is small, compared to that for ELF files (or jar files, which have a similar issue, as you've probably noticed). Not shipping .pyc files is definitely not the right thing to do, as Python will then create files (if it can) in directories that it's not supposed to be mucking around in, leaving turds around to be removed by the packaging system on package removal. > Could the build be modified to set the modification time for the source > files based on when they were actually modified in mercurial? This would be an interesting way of handling the problem. We still need the content hash for cases where this isn't done, but doing this would work. I'm not sure how difficult it would be to convince distutils not to change the timestamps when it copies things around, but it might be a fun thing for someone to look into if they're otherwise bored. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
