Skip to content

VMware SDK import fails on Python 3.12+ with setuptools >= 82 (pkg_resources removed) #497

@berlikm

Description

@berlikm

Description

netbox-sync shows Unable to import Python 'vsphere-automation-sdk'. Tag syncing will be disabled. even though the SDK is correctly installed.

The root cause is that vmware-vapi-runtime imports pkg_resources at runtime:

# vmware/vapi/l10n/bundle.py line 59
from pkg_resources import resource_string

But pkg_resources was:

  1. Removed from Python 3.12+ stdlibsetuptools is no longer bundled with Python
  2. Removed from setuptools >= 82.0.0 (released 08 Feb 2026) — the package that previously provided it

This means on any system with Python 3.12+ and setuptools >= 82, tag syncing is silently broken.

This affects both the old vsphere-automation-sdk AND the new vcf-sdk — both depend on vmware-vapi-runtime which uses pkg_resources.

Environment

  • netbox-sync: v1.8.0 (development branch, commit bb61e32)
  • Python: 3.12
  • setuptools: 82.0.0 (installed in venv)
  • VMware SDK: Tested with both:
    • Old: vsphere-automation-sdk==1.87.0 + vmware-vapi-runtime==2.52.0
    • New: vcf-sdk==9.0.0.0 + vmware-vapi-runtime==2.61.2
  • OS: Ubuntu (Debian-based)

Steps to Reproduce

  1. Install netbox-sync on Python 3.12+ with a fresh venv
  2. Install VMware SDK (either old or new):
    • Old: pip install git+https://github.com/vmware/vsphere-automation-sdk-python.git
    • New: pip install vcf-sdk
  3. pip installs setuptools >= 82 automatically (or user upgrades setuptools)
  4. Run netbox-sync → tag syncing is disabled
$ python -c "from com.vmware.vapi.std_client import DynamicID"
Traceback (most recent call last):
  ...
  File ".../vmware/vapi/l10n/bundle.py", line 59, in __init__
    from pkg_resources import resource_string
ModuleNotFoundError: No module named 'pkg_resources'

Workaround

Downgrade setuptools to a version that still includes pkg_resources:

pip install 'setuptools<82'

Known Upstream Issues

This is a known bug in the VMware/VCF SDK, tracked in the VCF SDK repo:

  • vcf-sdk-python#6 — "UserWarning: pkg_resources is deprecated as an API"

    • setuptools v82.0.0 completely removed pkg_resources, breaking vmware-vapi-runtime
    • VMware response: "The issue will be fixed in next major release of SDK" (no timeline)
    • SDK releases are coupled to VCF major releases only
  • vcf-sdk-python#4 — "vmware-vapi-runtime 2.61.2 requires old pyOpenSSL"

    • pyOpenSSL<24.3.0 pin creates dependency conflicts with newer packages
    • VMware response: "The current plan is to release SDKs with VCF major releases only"
  • vsphere-automation-sdk-python#443 — Same pkg_resources issue reported on the old (deprecated) SDK repo

Also affecting Ansible: ansible-collections/vmware.vmware#320

Suggested Fix

Since this is ultimately a VMware/Broadcom SDK bug (tracked in vcf-sdk-python#6), and there's no fix timeline from upstream, it would be helpful to document the workaround in the netbox-sync README so users don't have to debug this themselves.

Something like:

Note: On Python 3.12+ with setuptools >= 82, the VMware SDK import will fail because pkg_resources was removed. Run pip install 'setuptools<82' in your venv to restore tag syncing. See vcf-sdk-python#6 for details.

Future improvement: migrate to VCF SDK

The old vsphere-automation-sdk-python repo is deprecated/archived. VMware/Broadcom has moved to the VCF SDK (pip install vcf-sdk).

I tested VCF SDK 9.0.0.0 and confirmed it's a 1:1 drop-in replacement for tag operations — all imports are identical:

Import Old SDK VCF SDK
from vmware.vapi.vsphere.client import create_vsphere_client ✅ same
from com.vmware.vapi.std_client import DynamicID ✅ same
client.tagging.Tag, client.tagging.TagAssociation ✅ same

No code changes needed in netbox-sync — just swap the install command:

pip install vcf-sdk
# instead of: pip install git+https://github.com/vmware/vsphere-automation-sdk-python.git

Note: The setuptools<82 workaround is still required with VCF SDK today (vmware-vapi-runtime==2.61.2 still uses pkg_resources). VMware has acknowledged this in #6 and plans to fix it in the next major SDK release. Once that lands, the setuptools pin can be dropped.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions