On Thu, Sep 7, 2017, at 14:21, Antoine Pitrou wrote:
On Thu, 07 Sep 2017 14:08:58 -0700 Benjamin Peterson <benjamin@python.org> wrote:
On Thu, Sep 7, 2017, at 14:00, Antoine Pitrou wrote:
On Thu, 07 Sep 2017 13:39:21 -0700 Benjamin Peterson <benjamin@python.org> wrote:
Hello, I've written a short PEP about an import extension to allow pycs to be more deterministic by optional replacing the timestamp with a hash of the source file: https://www.python.org/dev/peps/pep-0552/
Why isn't https://github.com/python/cpython/pull/296 a good enough solution to this problem? It has a simple implementation, and requires neither maintaining two different pyc formats nor reading the entire source file to check whether the pyc file is up to date.
The main objection to that model is that it requires modifying source timestamps, which isn't possible for builds on read-only source trees.
Not sure how common that situation is (certainly the source tree wasn't read-only when you checked it out or untar'ed it), but isn't it easily circumvented by copying the source tree before building?
Well, yes, in these kind of "batch" build situations, copying is probably fine. However, I want to be able to have pyc determinism even when developing. Copying the entire source every time I change something isn't a nice.
This proposal also allows reproducible builds even if the files are being modified in an edit-run-tests cycle.
I don't follow you here. Could you elaborate?
If you require source timestamps to be fixed and deterministic, Python won't notice when a file is modified. The larger point is that while the SOURCE_EPOCH patch will likely work for Linux distributions, I'm interested in being able to have deterministic pycs in "normal" Python development workflows.