Move to filelock library

[Lotram]

lockfile has been deprecated for a long-time
while filelock is well-maintained

timeout message has changed because the existence of the lock file does not mean the file is actually locked anymore.
Locks are handled by the OS

Refs: #1183

[ryneeverett]

I'm going to merge this because it is an improvement but I'm questioning whether we need lock files at all in the medium term:

• I'm pretty sure I read that bitbucket issues are shutting down this year and since I believe bitbucket is the only consumer of BugwarriorData it will probably make sense to deprecate and remove it.
• I suspect the original reason we had a lockfile for the bugwarrior pull command is that we were using the TaskwarriorDirect backend from taskw which would open and manipulate the taskwarrior-2 json files. We've long since switched to the TaskwarriorShellout implementation which uses the taskwarrior command line interface, so I'm not sure there is any technical problem with concurrent bugwarrior processes. What do you think?

[Lotram]

I'm pretty sure I read that bitbucket issues are shutting down this year and since I believe bitbucket is the only consumer of BugwarriorData it will probably make sense to deprecate and remove it.

So I found 2 references to main_config.data, BitBucket, and Gmail.

• About Bitbucket, you're right, I found this , Issues are to be removed by mid-august apparently. I'm just not sure about their on-premise instances. They stopped BitBucket Server in 2024, but they now have BitBucket Data Center. I guess we can assume our own BitBucket service is for the cloud version ? In that case, we can start deprecate ?
• Gmail does not actually use the BugwarriorData object, it simply uses the taskwarrior location path (get_data_path). We could make this location path a property of MainConfig ? We could also decide to store the gmail creds file elsewhere, e.g. in bugwarrior cache, or bugwarrior config dir, as it seems there is no other use of this location path (except for the lockfile in command.py).

I suspect the original reason we had a lockfile for the bugwarrior pull command is that we were using the TaskwarriorDirect backend from taskw which would open and manipulate the taskwarrior-2 json files. We've long since switched to the TaskwarriorShellout implementation which uses the taskwarrior command line interface, so I'm not sure there is any technical problem with concurrent bugwarrior processes.

I guess it still makes sense to ensure we only have 1 instance of bugwarrior trying to create new tasks, but I don't have any strong opinion about this. We can remove it if you think it's useless

[ryneeverett]

* About Bitbucket, you're right, I found [this](https://community.atlassian.com/forums/Bitbucket-articles/Announcing-sunset-of-Bitbucket-Issues-and-Wikis/ba-p/3193882) , Issues are to be removed by mid-august apparently. I'm just not sure about their on-premise instances. They stopped BitBucket Server in 2024, but they now have BitBucket Data Center. I guess we can assume our own BitBucket service is for the cloud version ? In that case, we can start deprecate ?

I'm fairly sure our service will break in August (unless somebody contributes support for Bitbucket Data Center) and we can remove it when that happens. I don't think we should take any action in the meantime.

* Gmail does not actually use the `BugwarriorData` object, it simply uses the taskwarrior location path (`get_data_path`). We could make this location path a property of `MainConfig` ? We could also decide to store the gmail creds file elsewhere, e.g. in bugwarrior cache, or bugwarrior config dir, as it seems there is no other use of this location path (except for the lockfile in command.py).

Yeah, in hindsight it might make more sense to default to XDG_CACHE_HOME, but maybe we should still fall back to taskwarrior's data.location for portability reasons. (Unless there's a portable standard library interface to get the cache location?)

I guess it still makes sense to ensure we only have 1 instance of bugwarrior trying to create new tasks, but I don't have any strong opinion about this. We can remove it if you think it's useless

I suppose it makes sense to continue locking to avoid duplicate modifications so long as we're using the taskw backend. It may make more sense to do this at the transaction-level once we switch to taskchampion...we'll see.

[Lotram]

Unless there's a portable standard library interface to get the cache location?

I haven't used it, but there is https://github.com/tox-dev/platformdirs , from the tox-dev team

[Lotram]

platformdirs does support XDG variables properly, I think it would be a good candidate to simplify all the data path logic. Should we create an issue to discuss this ?

[ryneeverett]

Sure. I've found the freedesktop specs very easy to follow but the cross-platform support is more compelling since I know nothing about that.