simon-weber
Support for `FAKETIME_TIMESTAMP_FILE`
libfaketime has a FAKETIME_TIMESTAMP_FILE parameter, that points to a file containing the time to mock:
The README explains how this works:
Changing the 'x' modifier during run-time
Using FAKETIME_TIMESTAMP_FILE allows for easily changing the FAKETIME setting while a program is running:
echo "+0 x1" > /tmp/my-faketime.rc LD_PRELOAD=libfaketime.so.1 FAKETIME_TIMESTAMP_FILE="/tmp/my-faketime.rc" \ FAKETIME_NO_CACHE=1 ./some-program & sleep 10 ; echo "+0 x10" > /tmp/my-faketime.rc
I would love to be able to use this in python-libfaketime, so I could mock the time for a python-slapd server I run for tests, and dynamically change the mocked time while the server is running.
If this is OK with you, I would volunteer to provide a PR for this. I would love to hear your thoughts on the implementation though.
A simple version could look like this (the code is schematized, but you get the idea behind):
time_ctx = time_context(timestamp_file="/tmp/my-faketime.rc")
with time_ctx.fake_time('1970-01-01 00:00:01'):
server = AnyServer().run()
with time_ctx.fake_time('1980-01-01 00:00:01'):
response = client.request(server.url, payload)
assert response.payload.something == datetime(1980, 1, 1, 0, 0, 1)
with time_ctx.fake_time('1990-01-01 00:00:01'):
response = client.request(server.url, payload)
assert response.payload.something == datetime(1990, 1, 1, 0, 0, 1)
This introduces a new context object so several calls to fake_time will edit the same timestamp file, and impact all the processes that depends on it.
What do you think?
The main hurdle would be updating libfaketime. It looks like 0.9.8 added the timestamp file feature. python-libfaketime uses a forked version of 0.9.7 with some old changes that I barely remember the context of.
Sierra is EOL now so at least that version could be removed. It might be easier to start over from the current version of libfaketime and reintroduce my old changes as needed rather than try to merge the two.
It looks like 0.9.8 added the timestamp file feature.
Ah? I seems FAKETIME_TIMESTAMP_FILE is documented in your fork.
Anyways I suppose this would indeed be nice to have an up to date libfaketime version.
Do you remember what was the purpose of your changes? Was it related to the macOS support with python?
It looks like GHA has support for macOS. We could start by adding GHA tests for macOS 12 to 14, and check if an updated libfaketime version without changes would pass the tests. If so, would that be enough for you?
Hi @simon-weber I would love to go forward with this issue but I feel I really miss understanding about the libfaketime forking/update thing. Is this something you might tackle at some point? If not, could you please share the information you have on this (like, why the fork was needed in the first place) :pray: ?
These linked changes should be everything meaningful on the fork. I remember microsecond support being important. The other changes look mostly like removals to avoid having to update unneeded code.