'lockfile' is deprecated.

[dsully]

The 'lockfile' package required for file caching is deprecated.

https://pypi.python.org/pypi/fasteners is the recommended alternative.

[sigmavirus24]

Can you provide a reference for it's deprecation?

[dsully]

https://pypi.python.org/pypi/lockfile

"This package is deprecated".

[ionrock]

@dsully Thanks for bringing this up. Did you run into an issue with lockfile that is fixed with fasteners?

[dsully]

@ionrock: No, I ran into a dependency issue regarding 'pbr', which is declared as setup_requires for lockfile, but is actually used at package install time.

I notice that there is no equivalent to lockfile's MkDirLockFile class as well.

[dstufft]

I attempted to implement this, but I ran into an issue where it doesn't appear to actually be locking so I punted on it for the time being. However handling this in a compatible way might be tricky. There are a few scenarios that someone could be in currently:

1. They don't care about the type of lock used at all and just used the defaults.
2. They wanted to use directory locking and passed in use_dir_locking.
3. They specifically wanted to use a very particular lock class and passed that in specifically.

For the people in group 1, the main backwards compatibility concerns is whether or not cachecontrol wants to support compatibility with people running older and newer versions of the code at the same time. If it does not, then great, you can just switch to fasteners and not think about it. However if you do, then you'll need to be concerned about how to ensure that the existing lock file actually continues to cause a lock to happen, even with the new code.

For the people in group 2, you either have to remove this parameter or continue to support pylockfile when this parameter is chosen. This one is easy because you either continue to use the old code, or you just stop supporting it. However if fasteners ever gets something like MkDirLockFile then the same issue occurs as with group 1.

For the people in group 3, you don't have a lot of specific compatibility concerns as long as you ensure the lock API that you're using is compatible amongst both pylockfile and fasteners or you drop support for using specific pylockfile classes.

Finally, across all of these groups of people, anytime you allow mixing of pylockfile and fasteners based locks you'll run into another possible problem which isn't super hard to work around but you'll need to be aware. For Lockfile the API is LockFile("/some/path/I/want/to/operate/on") which will, under the covers, open up a lock like /some/path/I/want/to/operate/on.lock. However fasteners appears to be less specific to trying to lock operations on a specific file and instead it wants you to pass in the actual lock file itself, so it expects you to do fasteners.InterProcessLock("/some/path/I/want/to/operate/on.lock"). This becomes a larger problem if CacheControl continues to support both use_dir_lock and non fasteners lock_class arguments, so you'll need to pass in different arguments to the lock class depending on if you're using fasteners or pylockfile.

[dstufft]

Ok, I've got fasteners to work now, however the backwards compatibility questions still apply. I went ahead and pushed my branch to #114 but it's unlikely I'm going to spend anytime working on it in the near future, at least without answers to the above questions, some of which will require playing around with both pylockfile and fasteners and seeing what happens if both of them attempt to lock the same file (but even then, that won't solve things like the SQLiteLock).

[pradyunsg]

There's also https://pypi.org/project/filelock that seems to have a similar API as lockfile.

[tuxmaster5000]

Are any news here?
setup and install work without lockfile, but using it will fails with:
pkg_resources.DistributionNotFound: The 'lockfile>=0.9' distribution was not found and is required by cachecontrol

[frostming]

This is closed by #284