Skip to content

fix: avoid ImportError when pinecone loads as a namespace package#656

Open
rahulsolanki001 wants to merge 1 commit intopinecone-io:mainfrom
rahulsolanki001:fix/namespace-package-version-import
Open

fix: avoid ImportError when pinecone loads as a namespace package#656
rahulsolanki001 wants to merge 1 commit intopinecone-io:mainfrom
rahulsolanki001:fix/namespace-package-version-import

Conversation

@rahulsolanki001
Copy link
Copy Markdown

@rahulsolanki001 rahulsolanki001 commented May 8, 2026

Problem

On Python 3.11/3.12, in certain environments (stale pinecone-client
install, partial pip unpack, or installer edge cases), the pinecone
package can be resolved as a namespace package — where
pinecone.__file__ is None and dir(pinecone) shows only stdlib dunders.

In this state, three internal callsites crash at instantiation time:

ImportError: cannot import name 'version' from 'pinecone' (unknown location)

Affected files:

  • pinecone/_internal/http_client.py:20
  • pinecone/admin/admin.py:11
  • pinecone/grpc/__init__.py:167

The failure is deceptive: import pinecone and from pinecone import Pinecone
both succeed, but the crash only surfaces when Pinecone(api_key=...) is
first called.

Fix

Extract __version__ into pinecone/_version.py (single source of truth)
and redirect all three callsites to from pinecone._version import __version__.

Submodule imports resolve via _NamespacePath even when __init__.py is
not the active package root, so this import is robust to the namespace
package failure mode.

pinecone/__init__.py re-exports __version__ from _version.py — no
behaviour change for normal installs.

Also adds python-packages = ["pinecone"] to [tool.maturin] to make
package inclusion explicit rather than relying on auto-discovery.

Files changed

File Change
pinecone/_version.py New — __version__ = "9.0.0"
pinecone/__init__.py Import from _version instead of hardcoding
pinecone/_internal/http_client.py from pinecone._version import __version__
pinecone/admin/admin.py Same
pinecone/grpc/__init__.py Same
pyproject.toml python-packages = ["pinecone"]

Note

Low Risk
Low risk: changes are limited to how __version__ is defined/imported and a packaging config tweak; runtime behavior should be unchanged except avoiding ImportError in edge-case installs.

Overview
Fixes a startup crash in certain Python 3.11/3.12 edge-case installs where pinecone can be resolved as a namespace package by moving __version__ into a dedicated pinecone/_version.py module.

All internal callsites that used from pinecone import __version__ (HTTP client, Admin client, and gRPC client) now import __version__ from pinecone._version, while pinecone/__init__.py re-exports it for backward compatibility. Packaging is also tightened by explicitly listing python-packages = ["pinecone"] in the maturin config.

Reviewed by Cursor Bugbot for commit 2347683. Bugbot is set up for automated code reviews on this repo. Configure here.

Three internal modules imported __version__ directly from the package
root (`from pinecone import __version__`), which fails if `pinecone` is
ever resolved as a namespace package (e.g. stale pinecone-client install,
partial pip unpack, or installer edge case on Python 3.11/3.12) because
namespace packages expose no attributes beyond stdlib dunders.

Extract the version string into `pinecone/_version.py` and redirect all
three callsites to `from pinecone._version import __version__`. Submodule
imports resolve via the directory's `_NamespacePath` even when `__init__.py`
is not the active package root, so the import is robust to the failure mode.

`pinecone/__init__.py` is updated to re-export `__version__` from
`_version.py` rather than defining it inline, keeping a single source
of truth for the version string.

Also adds `python-packages = ["pinecone"]` to `[tool.maturin]` so the
package inclusion is explicit rather than relying on maturin's
auto-discovery heuristics.

Fixes: ImportError: cannot import name '__version__' from 'pinecone' (unknown location)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant