Reduce usage of pkg_resources

[abravalheri]

This is an attempt to reduce the usage of pkg_resources (and in some places to delay the associated import¹).

Summary of changes

The approaches used are:

• Whenever possible use packaging and importlib.metadata
• Create suitable replacements in the modules _normalization, _path
• Centralize the import/usage of pkg_resources to as few modules as possible (ideally only the ones that inevitably have to traverse deprecated code paths).
• Delay importing pkg_resources in an attempt saving the import cost when the module is not necessary.

---

• 6050634 - Replace pkg_resources in version.py
• ec238c4 - Extract normalization functions from editable_wheel and dist_info into _normalization
• 3c48e7c - Prefer _normalization to pkg_resources in develop.py
• daadc5a - Prefer _normalization and importlib_metadata to pkg_resources in dist.py
• 61ad58b - Prefer _normalization to pkg_resources in egg_info.py
• f8f56bc - Prefer packaging to pkg_resources in egg_info.py
• 6f93ec7 - Prefer packaging to pkg_resources in dist.py for markers
• cbd0cb7 - Prefer alternative from egg_info.py to pkg_resources.Distribution.egg_name
• 1cfd18b - Prefer packaging instead for pkg_resources for version in wheel.py
• dd7b8fb - Modify _reqs.py to favour packaging over pkg_resources
• e5681c0 - Centralize usage of pkg_resources from dist.py to installer.py
• 99b7b64 - Delay imports of pkg_resources in install_scripts.py
• 5e7b76f - Refactor/reorganize: replace _normalization.path with _path.samepath and _path.normpath
• 33f3243 - Fix dist-info naming discrepancy in relation to bdist_wheel
• 3736cbc - Revert to using normalized paths in develop to fix test errors

---

I created the following diagram manually (it can be incorrect) to represent the main modules where pkg_resources is still used after the change in the PR.

The red boxes represent the parts where it is very difficult to replace pkg_resources and we might just have to wait the end of the deprecation period to remove...

The yellow boxes represent parts to which I believe we could add explicit deprecations.

graph LR
  pkg_resources -->|delayed| setuptools.wheel.Wheel.install_as_egg:::can_deprec
  pkg_resources -->|delayed| setuptools.command.bdist_egg
  setuptools.command.bdist_egg --> setuptools.command.egg_info

  setuptools.dist.Distribuition.fetch_build_egg --> notoml[`pip install` for packages without pyproject.toml]
  setuptools.installer.fetch_build_egg:::critic --> setuptools.dist.Distribuition.fetch_build_egg
  pkg_resources --> setuptools.sandbox:::can_deprec
  pkg_resources --> setuptools.package_index:::can_deprec
  pkg_resources --> setuptools.installer.fetch_build_egg
  setuptools.sandbox --> setuptools.command.easy_install:::critic
  pkg_resources --> setuptools.command.easy_install
  setuptools.package_index --> setuptools.command.easy_install


  setuptools.dist.Distribuition.fetch_build_egg --> setuptools.command.develop

  pkg_resources --> setuptools.command.develop:::can_deprec
  setuptools.command.easy_install --> setuptools.command.develop
  setuptools.command.easy_install -->|delayed/conditional| setuptools.command.install_scripts


  setuptools.command.install_scripts --> setuptools.command.editable_wheel
  setuptools.command.install_scripts --> wheel.bdist_wheel

  pkg_resources --> wheel.bdist_wheel

  classDef critic fill:#fe0013
  classDef can_deprec fill:#fff386
  classDef is_deprec fill:#90ee90

Pull Request Checklist

• Changes have tests
• News fragment added in changelog.d/.
  (See documentation for details)

Footnotes

1. The idea behind delaying the import is that ideally only users that touch deprecated code paths should pay the cost of initializing pkg_resources. ↩

[jaraco]

I haven't reviewed this in detail, but love the broad strokes. Thanks for doing this work.