How the fuck is that a thing.

I understand when you're application requires a lock file. But put it in temp. I get it, you want it user specific. You can put it still in temp. Just add the user to the lockfile's name.

Don't put it in the config. Yea, had to reboot without letting my applications close properly. After a reboot, a lockfile should be automatically removed.

Here's an idea, if you're really that terrified of leaking the information, that the application is in use, to other users of the computer, which could probably just look at the processes to figure that one out, check the lock file's last modified timestamp and compare it with the uptime.

Because, it is just annoying when I reboot the computer and I cannot start the application because the fucking lockfile is still there.

Looking at you, datagrip. I really need to find a good open source alternative for my databases.

Dear Python linters, why can't any of you implement some actual linting features? Like, say, consistent use of single or double quotes? Or dict() vs {}? How about indenting nested function calls? Forcing list / set / dict literals as multiline? Trailing commas?

And while I'm at it, why can't you handle dependencies properly? Say, separating linter & linter plugins from the remaining dependencies in a way where I don't have to manually remove them from the requirements lockfile every time?

So I have replaced npm with yarn due to performance boost and the lockfile.

Never will there be problems with unexpected versions of dependencies!

Wait.

Why is my build writing a yarn.lock?

It turns out, if you want yarn to exit with an error code if it's out of sync with the package.json, you have to run it with:

$ yarn install --frozen-lockfile

Only then it will produce an error.

The default for it is to notice, oh, there is some new dependencies, let resolve this to the most current version I can fetch, and use that one, and write a new lockfile. Meaning you will get unknown futures of a depdency. O_o

That's totally going besides the purpose of having a lockfile in the first place. Why would anyone want this?

Action I do expect to touch the lockfile:

add / remove / upgrade

Action I do NOT expect to touch the lockfile:

install

Install should just install whatever is in there, and if it realizes it is out of sync, die with an error.

But that would make sense!

Who needs sensible defaults anyway!?