This looks fun. One quick improvement would be to rewrite the write and delete methods as a context manager, so that Python is able to release the PID lock in most cases, even after an unexpected exception.

I think .reportupdater.history logic was removed in 2851780a7594, I'll update the task description accordingly.

I'd like to understand better how this tool is used, so will read the docs. If it's actually run by cron, and production access is controlled by the Analytics team, then it might make sense to setuid, and store the PID file in /var/run. If people are free to run their own clone of the repo on production stat machines, then we would want per-user lockfiles rather than systemwide, amirite?

Hi @mforns , I am a first time contributor. I was looking at this task. While looking at the code, I saw that writing control files to home directory is pretty doable. So should I go ahead with this approach? Or do you want me to explore any further. Please opine.

Change 623470 had a related patch set uploaded (by Paul Kernfeld; owner: Paul Kernfeld):
[analytics/reportupdater@master] Use pid library to manage Pidfile

https://gerrit.wikimedia.org/r/623470

given that the missing pid package is now debianized let's deploy this code?

Change 623470 merged by Mforns:
[analytics/reportupdater@master] Use pid library to manage Pidfile

https://gerrit.wikimedia.org/r/623470

@paulkernfeld thanks for your work, woudl you be interested in doing more wikistats work (javascript) or you prefer these type of python projects?

No problem!

I would be happy to take a shot at Python or Wikistats work. If it helps in your planning, my goal is to spend like 3 hours per week on Wikimedia code.