Alternative get_locally_installed_packages() that uses pkg_resources
- Dominant language
- Python
- Stars
- 7.5k
- Forks
- 424
- PR merge metrics
- No merged PRs in 30d
Description
**Feature request**
Consider an alternative get_locally_installed_packages() that uses pkg_resources.
I anticipate pkg_resources.working_set will give subtlety different results than current get_locally_installed_packages(), but may be much faster than the recursively search through sys.path().
I'm uncertain of additional nuances.
So only execute pkg_resources "mode" with an explicit parameter/flag?
Notional example usage of pkg_resources.working_set within get_import_local()
```python
import pkg_resources
def get_import_local_via_pkg_resources(imports, encoding=None):
# local = get_locally_installed_packages() # original
local = {d.project_name.lower(): d.version for d in pkg_resources.working_set } # new
result = []
for item in imports:
if item.lower() in local:
result.append( {'name':item.lower(), 'version':local[item.lower()] })
# removing duplicates of package/version
result_unique = [
dict(t)
for t in set([
tuple(d.items()) for d in result
])
]
return result_unique
```
Ref. https://setuptools.readthedocs.io/en/latest/pkg_resources.html
Contributor guide
Research direction
Start with the existing get_locally_installed_packages() and get_import_local() implementations, then compare their recursive sys.path results with pkg_resources.working_set. Clarify how an explicit pkg_resources mode should be selected, account for differing package and version results, and verify that the completed alternative preserves the expected output format.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100