Set proper lower bound for portalocker dependency, drop packaging dependency

[Aarni Koskela (akx)]

packaging was only used as a dependency to check for the version of portalocker in use.

This drops that dependency and instead corrects the minimum version of portalocker to the one checked here.

It should be safe to depend on a version of portalocker that has been out for 3 years at this point, and is not quite as intrusive as #117 that would remove portalocker altogether (and in all honesty, that PR has been out there for a year, with no sign of merging).

[Aarni Koskela (akx)]

@microsoft-github-policy-service agree

[Ray Luo (rayluo)]

There is a history behind it.

packaging was only used as a dependency to check for the version of portalocker in use.

This drops that dependency and instead corrects the minimum version of portalocker to the one checked here.

It should be safe to depend on a version of portalocker that has been out for 3 years at this point

We started with portalocker=~1.6 in the first place, and then Luca Boccassi (@bluca) convinced us to relax the lower bound for Linux. If Luca Boccassi (@bluca) can chime in to say it is now OK to also use portalocker 1.6+ on Linux, we will consider this PR.

#117 that would remove portalocker altogether (and in all honesty, that PR has been out there for a year, with no sign of merging).

You can chime in in that PR and ping the reviewer there. That PR was developed based on a need at that time, but the integration test effort was suspended, so, there is little motivation to move forward.

[Aarni Koskela (akx)]

Ray Luo (@rayluo) Thanks for the feedback. My angle to this is trying to prune extra dependencies that aren't really needed – seems a waste to depend on (and download!) all of packaging just to be able to compare a version to another.

If, AIUI, not upgrading Portalocker is mostly the issue of more work for downstream Linux packagers, I understand and we'll need to deal accordingly, packagers can be an ornery bunch 😄

• It looks like Ubuntu 20.04 (still LTS supported) has python3-portalocker 1.5.1-1, so that would be an issue for pinning to 1.6+, but not to pinning to 1.4+ (which adds file_open_kwargs).
• Debian Bullseye (the oldest still supported Debian) has 2.2.1, not an issue.

(I don't quite know how to check for the other major distros.)

Maybe the heuristic for whether the file_open_kwargs can be passed could be done without an external dependency – some ideas:

• parse portalocker.__version__ "by hand" into a version_info style tuple and compare it
• check whether file_open_kwargs exists in the __doc__ for portalocker.Lock.__init__ – a bit hacky, maybe, but should do the trick?

[Aarni Koskela (akx)]

IOW, Luca Boccassi (@bluca), what do you think, would Portalocker >= 1.5 be a good middle ground 3 years after #49? 😁

[Luca Boccassi (bluca)]

IOW, Luca Boccassi (@bluca), what do you think, would Portalocker >= 1.5 be a good middle ground 3 years after #49? 😁

yes, fine by me

[Aarni Koskela (akx)]

Ray Luo (@rayluo) Okay, rebased + pushed a version that changes the pin to >= 1.4.