Speed up imports by removing pkg_resources

[wbarnha]

I created this PR to address issue #935, since I was having similar issues with imports. This PR is built off my previous PR #1105 since I think this change warrants more discussion.

Originally, python-can took four seconds to import. After removing the call to run iter_entry_points, the import time was down to three seconds. Removing the import call for pkg_resources reduced the import time by two seconds down to only needing one second for importing python-can.

I manually ran iter_entry_points in a similar setup as when the import process is run, to see if the dictionary for BACKENDS would change, but it seems nothing would change at all. Since everything is manually defined, it seems there's no need for iter_entry points?

Am I missing something here? I tested these changes with socketcan and I didn't have any issues.

[christiansandberg]

This is used for loading external interfaces as plugins (see https://python-can.readthedocs.io/en/develop/interfaces.html) so it's not possible to just remove it. You could however use importlib.metadata instead if possible, and fallback to setuptools on older Python versions.

[wbarnha]

This is used for loading external interfaces as plugins (see https://python-can.readthedocs.io/en/develop/interfaces.html) so it's not possible to just remove it. You could however use importlib.metadata instead if possible, and fallback to setuptools on older Python versions.

Okay, this was the response I was hoping to hear. I'll try the suggested changes and commit some additional changes

[wbarnha]

I think the last solution to this problem is making some architectural changes to how bus objects are initialized. A suggestion was made to initialize plugins on-demand, in order to reduce import time for other users.

[christiansandberg]

Just revert bus.py since it is related to another PR. Then I think it looks good.

[wbarnha]

Made the mistake of rebasing and had to revert my changes for canbus load calculations, but things should be fine.

I made some additional changes to allow older versions than Python 3.8 to only load user-installed interfaces on-demand. I really would like these features backported as well in order to improve import time for older versions of Python. But this brings up an issue where I can no longer have can.VALID_INTERFACES for Python 3.6 and 3.7 including the user-installed interfaces at runtime. I am willing to revert the changes so that the only change included is importlib.

[christiansandberg]

It's probably a limited number of users that rely on VALID_INTERFACES but since it is a breaking change I'm hesitant to include that. If one wants to take advantage of all optimizations they should update Python and other packages to the latest version. Python 3.9 will soon be the most commonly used version as it gets included in various distributions.

[wbarnha]

I think that's a reasonable issue. I'll go ahead and revert the last commit.

[pierreluctg]

Typically the imports would stay at the top of the module and use a feature flag (like use_importlib_metadata for example) to drive the logic bellow.

[hardbyte]

Nice, I wasn't aware of importlib's entry_points api.

[codecov]

Codecov Report

Merging #1110 (33b32d0) into develop (5b63bb2) will increase coverage by 0.01%.
The diff coverage is 88.88%.

@@             Coverage Diff             @@
##           develop    #1110      +/-   ##
===========================================
+ Coverage    70.49%   70.50%   +0.01%     
===========================================
  Files           79       79              
  Lines         7666     7672       +6     
===========================================
+ Hits          5404     5409       +5     
- Misses        2262     2263       +1