Add date and time of pip-compile to output #306
Conversation
Our use case involves checking to make sure that after someone has changed requirements.in that they have also made sure to rerun pip-compile. Does not change default behavior, by adding --date flag will the additional line be output.
| @@ -27,6 +29,8 @@ def write_header(self): | |||
| if self.emit_header: | |||
| yield comment('#') | |||
| yield comment('# This file is autogenerated by pip-compile') | |||
| if self.write_date: | |||
| yield comment('# On {} UTC'.format(datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S'))) | |||
There was a problem hiding this comment.
I agree UTC is unambiguous, but I'm not sure how useful it is. I think I'd prefer the local date for the user that last generated it. This is for human consumption after all.
|
While I can see that having a timestamp might be useful in general, I cannot see why it helps in your use case. btw: you can regenerate |
|
I agree with @blueyed here. You typically also check in the requirements.txt into version control, which should reflect the last time the file changed anyway. |
|
Thanks for taking the time to make suggestions! I really appreciate it. The problem is that if you have a requirements.in change that doesn't affect your requirements.txt, then there is no way to verify that someone regenerated the file without regenerating the file yourself. An example of this occurring happens when, say, you are using boto and you really cared about a feature from 2.8, so your requirements.in says Now I would like to check that if requirements.in changed, the user did, indeed, regenerate their requirements.txt. Most of the time that's easy (just check with There are two major issues with this strategy: First, pip-compile takes a while, so your unit tests job can slow down briefly. Not the worst, but it garners complaints. Second, and more nefariously, you get things like #277 cropping up, where your CI infrastructure is on a different platform (e.g., standard Amazon Ubuntu AMI) than your development boxes (e.g., standard Mac OS X). Anyway, that's the whole motivating story. Perhaps there's an easier solution that I'm not seeing? And local time makes sense, but our problem is that we have devs in a couple time zones, so it becomes a bit of a game either way. Perhaps default to local time but have date take an optional argument for a UTC offset? So you can always stipulate |
But the file being changed does not mean that it's correct?! You might want to add a check to your pipeline that does the real check, but possibly in a subtask on Travis/CI instead of in the regular developer's test suite. |
|
Closing this in favor of using file modification dates and/or VCS systems for tracking these dates. Thanks for the work/initiative though! |
Hi again!
This whole toolchain is great and we've incorporated it into our workflow, but we've found that people sometimes forget to recompile their requirements.txt files when they change their requirements.in files. It's easy enough to ask git for the list of files that changed in a commit, but even if the requirements.in changed, it's not necessarily true that the requirements.txt changed (e.g., a higher lower bound has a decent chance of not changing the version that pip-compile chooses).
So to make our check easier to implement (and much faster and lightweight) we wanted every requirements.txt file to have something slightly different in it, and the most convenient such thing is the date.
This PR adds a flag to pip-compile to include the date in the comments of the output requirements.txt. It does not change the default behavior.
Best and thanks again,
Kevin