Author eric.araujo
Recipients eric.araujo, jsjgruber, tarek
Date 2011-04-27.15:31:23
SpamBayes Score 6.61973e-07
Marked as misclassified No
Message-id <1303918286.59.0.419664555828.issue11933@psf.upfronthosting.co.za>
In-reply-to
Content
> Please note that I am not suggesting the code base use stat.st_mtime.
Yep, I did :)  Do you have another idea for a fix?  We have to walk on eggshells with the distutils codebase: it has often happened that changes made to fix bugs were causing problems in third-party code relying on undocumented behavior (and/or bugs), so we want to fix bugs without causing undesired effects.  (In the next-generation version, distutils2, we can break compatibility for the better.)

I think using only ST_MTIME or only st_mtime could prevent the bug you’re reporting without doing harm otherwise.

> Running the attached with ext4, which keeps sub-second file timestamps:
I think filesystems with this precision are becoming widespread.  Python 3 doesn’t have the bug AFAICT but Python 2.7 will be used for years, so it’s a worthwhile bug to fix.

> You can see under ext3 the newer() function of dep_util.py works
> correctly and the redundant copy of charley.py to the build
> directory, when setup.py is run a second time, is skipped. 
This would be particularly annoying with larger projects involving C extensions.  Would you be willing to turn your test file to a patch, and then fix the code?  We have some basic unit tests in test_dep_util.py and test_build_py.py, you could see how they work and add a test for this bug.  If you’re inclined to do so, please read the developpers guide at http://docs.python.org/devguide .  It not, thanks for what you’ve already done, and I’ll take up from here.
History
Date User Action Args
2011-04-27 15:31:26eric.araujosetrecipients: + eric.araujo, tarek, jsjgruber
2011-04-27 15:31:26eric.araujosetmessageid: <1303918286.59.0.419664555828.issue11933@psf.upfronthosting.co.za>
2011-04-27 15:31:24eric.araujolinkissue11933 messages
2011-04-27 15:31:24eric.araujocreate