PR: Sever the dependency on packaging.version (dependencies)

[davvid]

Make qtpy more self-contained by implementing our own simple version parse() function instead of relying on packaging.version.

[davvid]

One (minor?) downside is that this add a new function to the public API. If y'all agree that this is a good idea in general but would prefer for it to be private (or named differently) I'll happily rename it to _parse_version(...) or something along those lines. I just used the original name to minimize the diffs.

Thanks again for qtpy, BTW. I really appreciate the effort that has gone into this project.

[coveralls]

coverage: 90.017% (+0.3%) from 89.71%
when pulling 1fe2e9f on davvid:packaging-version
into 1d2a1ea on spyder-ide:master.

[ccordoba12]

Hey @davvid, nice to see you contributing to Qtpy again!

Make qtpy more self-contained by implementing our own simple version parse() function instead of relying on packaging.version.

I don't see much of a problem with this but could you better motivate the rationale for it? Does packaging add too many transitive dependencies for Qtpy?

One (minor?) downside is that this add a new function to the public API. If y'all agree that this is a good idea in general but would prefer for it to be private (or named differently) I'll happily rename it to _parse_version(...)

I was about to say that: the function should be renamed _parse_version and perhaps moved to the _utils module (in that case it should be named just parse_version).

@dalthviz, what do think?

Thanks again for qtpy, BTW. I really appreciate the effort that has gone into this project.

Thanks for git-cola too! Big fan until this day.

[dalthviz]

I think its fine but I'm curious too about why is better to not have packaging as a dependency. The one suggestion that occurs to me is to allow to use the packaging functionality if available as well as adding it as an extra/optional dependency. So basically go with a fallback approach where an attempt to use packaging.version.parse is done and if that errors go with the logic proposed here

[davvid]

Thanks for reviewing. I've updated the commit message to provide a little more rational. The basic idea is that this makes qtpy easier to vendor and use in environments where users don't already have packaging.version installed. Subjectively, packaging does seem like a pretty large dependency to bring along (over 5.6k of python code) just for the single parse() function, so the main motivation is minimalism and only paying for what we use.

Not that it matters, but I've been patching this change into a vendored copy of qtpy for a while now and it seems better to improve qtpy itself so that everyone can benefit. Being able to have a runtime environment that does not depend on packaging-related utilities seems like a win to me.

I implemented @dalthviz's suggestion to have our simpler _parse_version() try to use packaging.version.parse() and only use its internal version as a fallback. We now catch an ImportError when packaging.version is unavailable. I did this as a separate commit in case y'all decide that the simpler approach of just owning the logic ourselves is overall better/simpler. I can trivially drop that commit in case y'all are swayed.

Unfortunately, I was not able to move _parse_version() into the _utils module. The reason is that it would introduce a circular import dependency. The top-level __init__.py needs to use this function, and the top-level package is imported by _utils.py itself, so moving it there would introduce a cycle.

Going through that exercise did make me notice that _utils.py was using absolute (instead of relative) imports, so I added another commit that swaps it over to use modern relative imports instead. I rebased that change so that it comes before any of the other changes since it's more-so a cleanup / prep commit. This seemed okay to keep in this PR but let me know if y'all would prefer to split that out to a separate PR instead.

Thanks for considering this change. Cheers.