feat: Read plugin version from distribution, with fallback to package

[kgpayne]

In cases where the distribution name does not match the tap/target ID (also the package name by default) the Version reported in --about registers as [could not be detected].

e.g. tap-snowflake with package name tap_snowflake distributed as meltanolabs-tap-snowflake, to avoid PyPI name clashes.

Related to MeltanoLabs/tap-snowflake#8

---

📚 Documentation preview 📚: https://meltano-sdk--1254.org.readthedocs.build/en/1254/

[codecov]

Codecov Report

Merging #1254 (17a64b9) into main (2439682) will decrease coverage by 0.02%.
The diff coverage is 80.00%.

@@            Coverage Diff             @@
##             main    #1254      +/-   ##
==========================================
- Coverage   83.85%   83.82%   -0.03%     
==========================================
  Files          44       44              
  Lines        4150     4155       +5     
  Branches      718      719       +1     
==========================================
+ Hits         3480     3483       +3     
- Misses        490      491       +1     
- Partials      180      181       +1     

Impacted Files	Coverage Δ
singer_sdk/plugin_base.py	73.59% <80.00%> (-0.40%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[kgpayne]

Windows tests are failing, and I don't have an environment (or the familiarity of Windows+Python 😅) to debug. Given this doesn't cause a hard-fail (we simply get [could not be detected] in --about if no distribution and no package is found), I feel comfortable leaving the platform-specific xfail. Maybe a Windows-familiar community member will help us out in a future iteration 👍

[edgarrmondragon]

Does this mean the package name can't be retrieved in Windows?

[kgpayne]

It means the lookup via distribution will not work, yes. The fallback to metadata.version(cls.name) was the primary mechanism before this change (it relies on the library name being the same as the class name), though I don't know how well it worked for Windows in the first place 🤔

Given the hurdles we have to jump through to try and infer the plugin version via distribution or library metadata, I still think we are better off adding __version__ = "<version>" in __init__.py and importing that for --about. poetry-dynamic-versioning supports substitution from a 0.0.0 placeholder in any file (including __init__.py by default), and this approach is standard in other python packages 🤷‍♂️ This PR specifically addresses this ask from @aaronsteers 👍

[edgarrmondragon]

@kgpayne Yeah, I'd say it's probably not worth spending time trying to solve a problem that's only present when migrating existing taps and targets that are published to PyPI. Wdyt?

[cjohnhanson]

approved, pending that one open thread, but looks good to me

[kgpayne]

Closing in favour of __version__ = "<version>" in __init__.py solution:

I still think we are better off adding __version__ = "<version>" in __init__.py and importing that for --about. poetry-dynamic-versioning supports substitution from a 0.0.0 placeholder in any file (including __init__.py by default), and this approach is standard in other python packages 🤷‍♂️

[kgpayne]

Related issue:

• feat: support reading standard __version__ module attr when reporting --about version #1403