Remove use of pkg_resources for importlib.metadata

[banesullivan]

Follow up to #101 to use importlib.metadata as it is preferred. This refactors get_version() and the knowledge module quite a bit to remove unneeded logic as importlib.metadata.version can do much of (all?) what we need!

Further this, necessarily, drops support for Python 3.7.

Do not merge until we are ready to drop Python 3.7 support, which, IMO should match when PyVista drops 3.7 as that's the primary downstream dependency from my perspective

[prisae]

Earliest in July 2023: https://devguide.python.org/versions/#supported-versions (not that far away actually)

[banesullivan]

@prisae, so now importlib.metadata cannot find the dummy_module which makes sense, because it is not installed in the environment.... I'm tempted to remove that and say it's an invalid scenario. But first, I'd like to do some testing to make sure all of this works with conda as well

[prisae]

It should work. And I don't think it is that an uncommon scenario, in my experience working with people...

[banesullivan]

But first, I'd like to do some testing to make sure all of this works with conda as well

All works with conda-installed packages

[prisae]

A few comments, take what you like and leave the rest.

[prisae]

A couple of locations are checked, and we are happy to implement more if
needed, just open an issue!

This could potentially also be removed.

[prisae]

Maybe the entire section could be removed. Anyway, it is funny, as it will shift the focus of scooby. A big part of scooby was to find the version number in all potential odd situation. Which was sort of the detective part. Now, using importlib, scooby sort of (at least for the versions) is merely a display tool. Which is not a bad thing at all, but it is interesting to see where the whole thing came from and where it goes.

[prisae]

I wonder if there would be a "latest" or "latest-1" flag or so, such that this has not to be manually adjusted every now and then. (Nothing to do with this PR though.)

[prisae]

I wonder if there would be a "supported" or "official" flag or so, such that this has not to be manually adjusted every now and then. (Nothing to do with this PR though.)

[prisae]

The following lines will potentially have to be adjusted:

>>> scooby.get_version('no_version')
('no_version', 'Version unknown')
>>> scooby.get_version('does_not_exist')
('does_not_exist', 'Could not import')

[prisae]

This statement has a tone of judgement, and I would prefer scooby to not be opinionated about how users do things, I do not think it is the scope of scooby.

Having a local module is a valid scenario, and if a users decides to do so it is not helpful by always slapping in its face "not properly installed". E.g., a folder full of notebooks, with a small local "module"-folder in it that is accessed by all notebooks. This is only meant to be local, never used anywhere else. This might even be versioned. I think that happens more than you might think.

As such, I would prefer a short string, free of judgement. E.g., (local), (sys.path), or similar.

[prisae]

I am always reluctant too have to many returns, but that is personal preference. What about

        if ver is None:
            ver = VERSION_NOT_FOUND
        ver += f' {NOT_PROPERLY_INSTALLED}'

and then it is returned at the end?

[prisae]

It is an interesting PR. So ideally every "detective" work within scooby should be replaced by things from the standard library, if they are implemented. So scooby will become, over time, less and less "detective" and reduces to "report". It is a good long-term goal! ;-)