Read lock danger about portalocker

[wolph]

That's a bit of a legacy issue unfortunately, while I agree with you that it's illogical I'm not a big fan of changing behaviour. This library is used by many others in many locations so besides introducing a new API I don't see a simple fix for the issue.

[petef4]

Well yes, it is the API that I find to be broken, in ways not present on the upstream ActiveState recipe. A read lock ought not to be concerned with truncate. Defaulting to an effective mode="w" when the signature has mode="a" violates POLA.

The standard way forward for you would be to bump the major version to indicate an API change. For my purposes I should stick to the lower level fcntl as I only need to run on Linux.

[wolph]

You're correct that it's not in the original ActiveState recipe but it was this way when I forked it a long time ago. The initial version found in this repo is how I found it at that time which means that there are people using in in this fashion. If people expect truncate but get append instead, applications will break in weird ways.

A major release bump can still be automatically installed if people simply specified portalocker as a requirement so that is definitely not an option. A new API to replace the old is an option but only with proper deprecation warnings for the old API.

[petef4]

Fair enough. Personally I consider it best practice to use explicit versioning in requirements.txt. I'll leave you to support your legacy dependents and move on.

[wolph]

It's definitely a valid point so I will add an API with a new and safer version.

[wolph]

The new version 1.0.0 fixes this issue and is therefore backwards incompatible with the old version.