ENH: drop dependency to packaging, use tuples to parse and compare version numbers

[neutrinoceros]

PR Summary

replaces #3600. Addionally to reducing duplicated code:

• code is less verbose
• one less dependency
• as a bonus, comparing tuples is 100x faster than parsing and comparing objects, though it should never really matter in practice

keeping this as a draft for now, conflicting PRs should be prioritised over this one:

• BUG: fix two bugs with symlog colorbar ticks for matplotlib 3.5 #3556
• BUG: fix for matplotlib 3.5 + symlog + linthresh value outside data range #3565
• DEPR: deprecation cycle (4.0 -> 4.1) #3240

[neutrinoceros]

dropping this completely because setup.cfg requires h5py >= 3.1 anyway

[neutrinoceros]

@yt-fido test this please

[munkm]

Considering how little version comparisons happen in the codebase, is there really a major speedup here? It seems like the packaging import makes the code nicely readable, and I don't see the verbosity a downside in this case.

[neutrinoceros]

Considering how little version comparisons happen in the codebase, is there really a major speedup here?

definitely not, sorry if this wasn't clear.

It seems like the packaging import makes the code nicely readable

Matters of opinions on this point I guess. I find that tuple comparison is at least as readable, as well as more consistent with the idiomatic way to check Python's version at runtime using sys.version_info.

Historically, we used to rely on distutils.version.LooseVersion. That class was convenient because it was forgiving to version strings not following the semantic version pattern, and could basically compare any two strings we threw at it.
distutils is however deprecated from the standard library, which is why we migrated to packaging.version.parse, the recommended replacement, which was equally forgiving (see #3385).
Having packaging as an additional dependency however became less justified because they're planning to remove the flexibility of the packaging.version.parse function (by dropping packaging.version.LegacyVersion, equivalent to distutils.version.LooseVersion). Now we're using packaging.version.Version, which has none of the flexibility LooseVersion used to have (see #3494)

I figure, having one simple internal function to maintain looks more and more like an easier choice than aiming for the moving target that is version parsing in the ecosystem.

[matthewturk]

I don't want this to be interpreted as suggesting we not do this PR, but I want to put out there that I am pretty ambivalent to changes like this. I'm not opposed, but like @munkm , I don't always understand the priority of it, and I think that maybe it's okay to let things like this slide.

[neutrinoceros]

Well this isn't a hill worth dying on. If you guys don't see value in this I'll just close it.

[matthewturk]

I mean, that really wasn't what I was getting at.

[neutrinoceros]

It's fine. I have more open PRs than I can decently handle anyway, and this one wasn't going to be mergeable for at least a couple weeks. I'll consider reopening it if packaging bothers me again

[tony]

It's fine. I have more open PRs than I can decently handle anyway, and this one wasn't going to be mergeable for at least a couple weeks. I'll consider reopening it if packaging bothers me again

@neutrinoceros

Could I use your version_tuple (link) in libtmux? I am struggling with this in a PR of my own tmux-python/libtmux#348 prefer yours. Could you even PR the function to libtmux, or could I copy it in under MIT license and modify as needed?

P.S. I think you were on to something here, after pypa/packaging#465. Removing the reliance on packaging, seeing as it's flexibility isn't there anymore

[neutrinoceros]

Hi @tony, thanks for asking. I'm happy to contribute this function to libtmux, I'll open a PR or join the discussion there if I need any guidance.