Setting Up a Python Environment With uv

Every Python project starts with the same decision: how do you manage the interpreter and its dependencies without one project's packages leaking into another? That question is what this post answers, using the setup from the first session of an AI Forward Deployed Engineer bootcamp I ran.

The tool: uv

There are three common ways to install Python. The python.org installer is simplest, but it only gives you one Python version at a time on the machine. Anaconda/Miniconda bundles a full data-science toolkit and can juggle multiple Python versions, but it's heavy for most projects. uv sits in between — lightweight, and it manages multiple Python versions through named virtual environments, so switching between a legacy 3.4 project and a new 3.12 project is instant instead of an install/uninstall cycle.

Creating and syncing an environment

From the project root:

uv venv --python 3.12
uv sync

Activating it:

source .venv/bin/activate

On Windows it's .venv\Scripts\activate instead.

Running code without activating

The part that actually changes daily habits: uv run finds the project's .venv automatically, so you don't need to activate anything just to run a script.

uv run hello.py

A minimal script to confirm the environment works:

def greet(name: str) -> str:
    return f"Hello, {name}!"


print(greet("Vikesh Singh"))

Editor, hybrid IDE, or full IDE

Three tiers, and picking the wrong one wastes either time or resources:

An editor (Notepad, nano) edits files and nothing else — no dev tooling. A hybrid IDE like VS Code adds an integrated terminal, debugger, and extensions (AI agents, Docker, cloud connectors) while staying lightweight — that's what I use day to day. A full IDE like PyCharm is language-specific and feature-rich, but heavier on RAM, CPU, and storage than most work actually needs.

Why the CLI matters more than it looks

Servers typically have no UI at all — just an OS, usually Linux, reachable only through a terminal. If you've only ever worked in a GUI, that's the gap to close first, because CLI fluency isn't optional once you're deploying anything.

The working style I'd recommend

Bring debugging and implementation questions — "I'm getting this error," "how do I do X" — to an LLM first, and save genuine conceptual doubts for a person. No single LLM is "best" here; try a few and compare how they handle the same question.