update timestamp of destination files not source files

[DancingQuanta]

I have faced a similar situation as the #767 where I use make to automate shell commands. My workflow consists of

markdown [jupytext]-> notebook [jupyter convert]-> output

I do want to keep both markdown and notebook paired.
The current Jupytext modifies the input markdown file's timestamp which keep make seeing it as newer than notebook output files.

I wonder if it is possible to set the timestamp of the notebook output files is set to equal that of the input files? Could this be an option?

[mwouts]

Hi @DancingQuanta , well this sounds like a great idea!

I don't think I would risk doing that by default, but maybe indeed we could have an option to set the timestamp of the output file equal to that of the input. What name would you choose for that option? Something like --use-source-timestamp?

[DancingQuanta]

I understood that you have developed this library so far with the timestamps being synchronized to the destination files and changing this behaviour is a disruptive change and is that why I suggested an option.

We could use --use-source-timestamp argument as you suggested as I do not have any other ideas.

I think the next step would be to introduce this feature through a PR to test because I wanted to be sure that this new timestamp setting behaviour will resolve my Makefile issue. I will study the code and I think I have to target the pairing code and add a test to the test suite.

[mwouts]

I think the next step would be to introduce this feature through a PR to test because I wanted to be sure that this new timestamp setting behaviour will resolve my Makefile issue. I will study the code and I think I have to target the pairing code and add a test to the test suite.

Yes, that would be great! I would say that you will have to modify lazy_write at jupytext/cli.py:719. And for the tests maybe you can take some inspiration in tests.test_cli.test_jupytext_to_ipynb_does_not_update_timestamp_if_output_not_in_pair.

However if you are not in a hurry I could also prepare the PR - the next release should be a matter of a few weeks.