This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author db3l
Recipients db3l, ned.deily, pitrou, ronaldoussoren
Date 2011-03-13.22:20:50
SpamBayes Score 3.930478e-11
Marked as misclassified No
Message-id <>
Just a few thoughts that were in part in an earlier exchange with Antoine.

It seems to me that if the Python-ast.[ch] files are included in the repository then they ought to be up to date as part of any given change set.  So I think I'd actually prefer having them touched in the master copy to avoid needing to be rebuilt (e.g., what presumably has been true up until this most recent change, although I'm not sure if switching to hg has changed something in this area).

If that isn't feasible (but the files are still in the repository) then there probably does need to be some way for the build-installer process to permit a more-recent-than-system python to be used.  However, it goes to some lengths (understandably) to avoid the risk of corruption from local system files, so it's not clear how to generically make a build script that uses "/usr/bin/env python" to work.

Manually touching the output files, either by build-installer, or a separate step in the build process controlled by the master (like the current umask step) seems to be least attractive, since there's no way to know for sure that the files are really up to date that way, right?  If they are up to date, then a checkout ought to reflect that, no?

-- David
Date User Action Args
2011-03-13 22:20:51db3lsetrecipients: + db3l, ronaldoussoren, pitrou, ned.deily
2011-03-13 22:20:50db3lsetmessageid: <>
2011-03-13 22:20:50db3llinkissue11487 messages
2011-03-13 22:20:50db3lcreate