Issue Summary
On v26.3.0, the Vertica data source type is unavailable, it doesn't appear in the "New Data Source" type list. When migrating an existing Redash deployment to v26.3.0, any existing Vertica data source becomes inert.
Root cause: pyproject.toml pins vertica-python = "1.1.1", and that version's password.py does an unconditional import crypt on non-Windows platforms. Python 3.13 (which v26.3.0 also targets) removed the crypt module from the standard library (PEP 594), so this raises ModuleNotFoundError at import time.
Steps to Reproduce
- Pull and run the official v26.3.0 Redash Docker image directly.
- Open the "New Data Source" dialog and search for "Vertica".
- Observe that Vertica does not appear anywhere in the list of available data source types.
Confirmed the root cause against the source at the pinned version: vertica_python/vertica/messages/frontend_messages/password.py in vertica-python==1.1.1 does:
if os.name == 'nt':
from . import crypt_windows as crypt
else:
import crypt
with no fallback for crypt's removal in Python 3.13
Partial fix already exists upstream, but incomplete: vertica-python v1.1.2 (also present in the current v1.1.3) wraps this import in a try/except, falling back to cryptography.hazmat.primitives.hashes. But it has a comment acknowledging: "Note: hashes doesn't replace 'crypt', review usage", the legacy CRYPT_PASSWORD Vertica auth method could still break at runtime even on >=1.1.2.
Suggested fix: bump pyproject.toml's vertica-python pin from 1.1.1 to >=1.1.2 (currently v1.1.3), which resolves the reported symptom for all auth methods except the legacy CRYPT_PASSWORD path.
Workaround (until fixed upstream): we shimmed the standard library's removed crypt module using legacycrypt which fully restores the old crypt.crypt() API rather than relying on vertica-python's incomplete fallback:
RUN pip install --no-cache-dir legacycrypt && \
SITE_PACKAGES=$(python3 -c "import site; print(site.getsitepackages()[0])") && \
printf 'from legacycrypt import * # noqa: F401,F403\n' > "$SITE_PACKAGES/crypt.py"
Technical details:
- Redash Version: v26.3.0
- Browser/OS: N/A — this is a server-side Python import failure at application startup, not browser-specific
- How did you install Redash: Official v26.3.0 Docker image with a thin custom Dockerfile layered on top (a patched query runner file, and unrelated user/group setup, doesn't touch Python dependencies).
Issue Summary
On v26.3.0, the Vertica data source type is unavailable, it doesn't appear in the "New Data Source" type list. When migrating an existing Redash deployment to v26.3.0, any existing Vertica data source becomes inert.
Root cause: pyproject.toml pins vertica-python = "1.1.1", and that version's password.py does an unconditional import crypt on non-Windows platforms. Python 3.13 (which v26.3.0 also targets) removed the crypt module from the standard library (PEP 594), so this raises ModuleNotFoundError at import time.
Steps to Reproduce
Confirmed the root cause against the source at the pinned version: vertica_python/vertica/messages/frontend_messages/password.py in vertica-python==1.1.1 does:
with no fallback for crypt's removal in Python 3.13
Partial fix already exists upstream, but incomplete: vertica-python v1.1.2 (also present in the current v1.1.3) wraps this import in a try/except, falling back to cryptography.hazmat.primitives.hashes. But it has a comment acknowledging: "Note: hashes doesn't replace 'crypt', review usage", the legacy CRYPT_PASSWORD Vertica auth method could still break at runtime even on >=1.1.2.
Suggested fix: bump pyproject.toml's vertica-python pin from 1.1.1 to >=1.1.2 (currently v1.1.3), which resolves the reported symptom for all auth methods except the legacy CRYPT_PASSWORD path.
Workaround (until fixed upstream): we shimmed the standard library's removed crypt module using legacycrypt which fully restores the old crypt.crypt() API rather than relying on vertica-python's incomplete fallback:
Technical details: