Python environments and managing Python dependencies have been a bit of a pain point for SAS Viya users and administrators. In SAS Viya today, installing Python packages into the shared Python environment requires Kubernetes administrative access. There are both advantages and disadvantages to this approach. On one hand, it provides strong governance, stability, and control. Organizations can establish robust processes to review, approve, and manage third-party dependencies within their environment. For organizations with strict security, compliance, or regulatory requirements, this centralized model is often exactly what is needed.
But, for teams that are focused on rapid experimentation and development the same controls can introduce friction. Trying a new library, testing an updated package version, or working on multiple projects with conflicting dependency requirements may require platform-level changes that are not always practical or desirable.
It's important to recognize that neither approach is inherently better. They are optimized for different objectives. SAS Viya's centralized management model prioritizes governance, consistency, and operational stability. Development-focused workflows, on the other hand, often prioritize flexibility, experimentation, and project-level isolation. Fortunately, the Python ecosystem has evolved significantly in recent years to address these challenges.
Managing Python dependencies has historically involved a combination of tools such as pip and virtual environments. While these tools remain widely used, the Python ecosystem has seen the emergence of additional solutions such as Conda, Pipenv, Poetry, and others, each attempting to simplify dependency management, environment reproducibility, and developer productivity.
More recently, a tool called uv has gained significant attention within the Python community. Built in Rust (you have to say this when something is written in Rust), uv combines Python version management, virtual environment management, dependency resolution, package installation, and project execution into a single tool. Rather than requiring developers to stitch together multiple utilities and workflows, uv provides a streamlined and highly performant experience for managing Python projects.
While its performance is impressive, the real value of uv lies in the way you can create reproducible, project-specific environments. Each project can define its own Python version and dependency requirements without impacting other projects or users. This project-centric model aligns naturally with the way many engineers and data scientists work. One project may require an older version of pandas for compatibility reasons, while another may a novel AI library. Rather than forcing every project to conform to a single shared runtime, each project can maintain its own isolated environment.
This is where SAS Viya Workbench excels. While SAS Viya focuses on centrally managed runtime environments, Workbench is designed to support the daily workflows of developers, data scientists, and analysts. Workbench provides users with a persistent home directory, and the ability to mount one or more shared volumes to run and store project files and data. Using uv in Workbench allows users to:
Rather than replacing the strengths of the SAS Viya model, Workbench complements it by enabling greater flexibility during development and experimentation while preserving project-level isolation.
The following instructions assume that you have created and opened your Workbench using the "Launch VS Code - SAS and Python" option. Once you're in your Workbench, you'll want to open VS Code's terminal, you can do that by going "View - Terminal", or by using the keyboard shortcut "Ctl + `".
SAS Viya Workbench does not include uv out of the box. Fortunately, installing it is simple and only needs to be done once since by default it installs into our home directory which gets mounted to every Workbench we launch. Using the standalone installer simply run:
curl -LsSf https://astral.sh/uv/install.sh | sh
You should see output similar to:
installed uv to ~/.local/bin
installed uvx to ~/.local/bin
We can verify that the installation was done correctly by running:
uv --version
Example output:
uv 0.8.x
With uv installed, you're ready to manage Python versions and projects.
One of the first benefits of uv is the ability to manage multiple Python versions. To see available and installed versions:
uv python list
You can install a specific version of Python with a single command:
uv python install 3.11
Or install a newer version:
uv python install 3.12
After installation, verify the available runtimes:
uv python list --only-installed
This allows different projects to target different Python versions without requiring platform administrators to provision additional runtimes.
Let's create a simple project:
mkdir forecasting-demo
cd forecasting-demo
uv init
This creates a new Python project structure containing files such as:
forecasting-demo/
├── pyproject.toml
├── README.md
└── main.py
The pyproject.toml file becomes the central definition of your project's dependencies and configuration.
If you want your project to use a specific Python version, pin it:
uv python pin 3.11
This creates a .python-version file within the project.
Now anyone working with this project understands which Python version it is expected to use.
Installing dependencies is straightforward. For example, let's add some common analytics libraries:
uv add pandas
uv add saspy
uv add matplotlib
Behind the scenes, uv:
Your pyproject.toml file will now contain entries similar to:
dependencies = [
"pandas",
"saspy",
"matplotlib"
]
Unlike a shared platform environment, these dependencies belong only to this project.
Create a simple script called revenue.py:
import pandas as pd
df = pd.DataFrame({
"Month": ["Jan", "Feb", "Mar"],
"Revenue": [100, 125, 140]
})
print(df)
Run the script using uv:
uv run revenue.py
One of the conveniences of uv is that there is no need to manually activate a virtual environment first.
The correct project environment is used automatically.
Reproducibility is one of the most valuable aspects of modern Python tooling. Imagine a teammate clones your project:
git clone <repository>
cd forecasting-demo
Rather than manually installing packages one by one, they simply run:
uv sync
uv reads the project's dependency definitions and recreates the environment automatically.
This helps ensure that everyone working on the project is using the same dependencies and Python version, reducing the "works on my machine" problem that many development teams encounter.
SAS Viya Workbench is optimized for a specific phase of the analytics lifecycle. SAS Viya's centrally managed environment provides governance, stability, and operational consistency, all of which are essential for many production workloads. SAS Viya Workbench complements this model by empowering developers and data scientists with greater control over their own development experience.
Tools such as uv make it easy to install Python versions, manage project dependencies, create isolated environments, and reproduce those environments across teams. Combined with Workbench's persistent home directories and developer-focused experience, uv enables a modern Python workflow that aligns well with the needs of analytics developers.
The result is a balance between organizational governance and developer agility, allowing teams to move quickly during experimentation while maintaining the controls needed for enterprise analytics.
Thank you for this article and sharing these techniques and experience.
Is there a way to control where uv gets its Python packages from? We need to control which channels used within uv due to security restrictions and ensure only vetted packages make it to our deployments.
@ahmedalattar you absolutely can control where the packages come from. uv can be configured to use other package indexes, including private indexes: Package indexes | uv
It's your turn to help shape SAS Innovate 2027. Share your expertise and inspire the SAS community.