It became apparent in a Python community discussion[0] yesterday that lockfile has been designated as a "critical project" by PyPI, even though it was effectively abandoned in 2010. Because our release automation account is listed as one of its maintainers, I looked into whether we still need it for anything... For those who have been around here a while, you may recall that the OpenStack project temporarily assumed maintenance[1] of lockfile in late 2014 and uploaded a few new releases for it, as a stop-gap until we could replace our uses with oslo.concurrency. That work was completed[2] early in the Liberty development cycle. Unfortunately for us, that's not the end of the story. I looked yesterday expecting to see that we've not needed lockfile for 7 years, and was disappointed to discover it's still in our constraints list. Why? After much wailing and gnashing of teeth and manually installing multiple bisections of the requirements list, I narrowed it down to one dependency: ansible-runner. Apparently, ansible-runner currently depends[3] on python-daemon, which still has a dependency on lockfile[4]. Our uses of ansible-runner seem to be pretty much limited to TripleO repositories (hence tagging them in the subject), so it's possible they could find an alternative to it and solve this dilemma. Optionally, we could try to help the ansible-runner or python-daemon maintainers with new implementations of the problem dependencies as a way out. Whatever path we take, we're long overdue. The reasons we moved off lockfile ages ago are still there, and the risk to us has only continued to increase in the meantime. I'm open to suggestions, but we really ought to make sure we have it out of our constraints list by the Zed release. [0] https://discuss.python.org/t/17219 [1] https://lists.openstack.org/pipermail/openstack-dev/2014-June/038387.html [2] https://review.openstack.org/151224 [3] https://github.com/ansible/ansible-runner/issues/379 [4] https://pagure.io/python-daemon/issue/42 -- Jeremy Stanley