Python Environment Setup for SageMaker

Most SageMaker deployment failures that look like AWS problems are actually Python environment problems: wrong Python version, broken dependency resolution, stale SDK that doesn't know about a current API. This skill makes env setup boring and correct.

Core rules

1. Never use the system Python. Always work inside an isolated environment.
2. Pin the Python version, not the package versions. Use 3.10, 3.11, or 3.12. Avoid 3.13+ — ML libraries lag on wheel availability and dependency resolution breaks in confusing ways.
3. Install the latest of each package. Don't defensively pin boto3 or awscli. Newer ones have current API surfaces and security fixes. Only pin if the user explicitly requires a specific version.
4. Check installed versions correctly. Use importlib.metadata.version("package-name"), never module.__version__. The latter is inconsistent across packages.
5. The bundled scripts use boto3 directly. The SageMaker Python SDK is a valid alternative — see "boto3 vs the SageMaker SDK" below.

boto3 vs the SageMaker SDK

The bundled deploy scripts (deploy.py, deploy_async.py, teardown.py) use boto3 directly and read image URIs from AWS's published Deep Learning Containers catalog. That fits this workflow's explicit-stages design — each skill produces a concrete value (region, role ARN, image URI) that the next one consumes — and boto3 is the stable underlying API client.

The SageMaker Python SDK (v3) is fine to use when the user prefers it or their project already does. Since PR #5960 (June 2026), ModelBuilder auto-routes HuggingFace models to the current containers (text-generation → HuggingFace vLLM, multimodal → vLLM-Omni, embeddings → TEI). Don't avoid the SDK over stale-image or wrong-container concerns — that routing is fixed.

Two specific SDK cases that still need care: