February 1: UV Package Manager and AI Agent

Hello everyone! It’s been a while since my last log. I’ve been quite busy lately, but here I am. Cheers to the new update!

Jumping into the development world, I’ve completely switched to uv for my Python project development. The package management is quite good, and the package resolution is FAAAAASST!! Gone are the days of waiting for dependencies to resolve when adding a new package. Working with pyproject.toml has been awesome so far.

So far this year, I’ve worked on py-requests-logger. In simple terms, it’s a package to log HTTP requests and replay them as needed. The project is still ongoing, and I’m planning some fun things in the upcoming days. This project was born out of my frustration with “microservice” architecture (or “distributed monolith,” as I like to call it), where you’re working with an API that requires a Celery task to generate some data, passes it to another API which uses the same data to generate more data, and finally hits the API you’re working with. Please provide your feedbacks, if any. Insert frustration emoji/pic here.

Recently, I’ve also become interested in the agentic capabilities of LLMs with all the hype going around. Shoutout to Atomic Agents for making me not use LangChain. I could have just used an LLM library to develop my own solution, but Atomic Agents was easy enough to start with—though the documentation needs some improvement. Overall, LLM capabilities have increased quite a lot since last year, and I’m thinking of working more on these kinds of projects in the future.

As always, I’m trying to improve my development workflow. I loved working with pyenv, and in my earlier blogs, I shared some scripts that enhance my flow with it. This time, with the use of the uv package and its virtualenv integration, I’ve moved past it. Unlike pyenv, which keeps virtualenvs in the user’s directory, uv encourages using the project directory for the venv. So, I’ve come up with a script to automatically enable the venv whenever I find a .venv in the directory.

auto_venv () {
    local current_venv="$VIRTUAL_ENV"

    # Check if .venv directory exists in the current directory
    if [[ -d ".venv" ]]; then
        # If we're not already in this venv
        if [[ "$current_venv" != "$PWD/.venv" ]]; then
            # Deactivate any existing venv
            [[ -n "$current_venv" ]] && deactivate

            # Activate the new venv
            source .venv/bin/activate
        fi
    else
        # If we're in a venv and there's no .venv in current directory
        # Check if we need to deactivate (we've left a venv directory)
        if [[ -n "$current_venv" ]] && [[ "$PWD" != "$current_venv"* ]]; then
            deactivate
        fi
    fi

}


chpwd_functions+=(auto_venv)

Adding this script to the .zshrc file adds functionality to the cd command to run the auto_venv function whenever the directory changes. It’s not much, but it’s one less thing to worry about when working on a project.

Anyway, that’s all for now. Peace!