Forem: Jesse Casman

HowTo: Start a Python Project with `uv` and Build Your First Flet UI App

Jesse Casman — Sun, 08 Mar 2026 22:51:00 +0000

If you want to learn Python by building practical, portfolio-friendly projects, not just isolated coding exercises, check out the free course Industry Projects for Python

In this tutorial, from Chapter 1, you will use uv to create a new Python project, install Flet, and run your first simple desktop UI app.

If you are a computer science student or early-stage developer, this is a strong pattern to learn because it combines three useful ideas at once: modern Python tooling, clean project setup, and a visible app you can actually show someone.

A lot of newer Python developers start with pip, and that makes sense. pip is the standard installer, it is everywhere, and you need to know it. But once you start building actual projects, especially projects you may want to demo, maintain, or share with other people, a more structured workflow helps. That is where uv stands out. Instead of just installing packages into the void, uv helps you create a real project from the start, with an isolated environment and dependency tracking built in.

It also reinforces one of the most important Python habits early: project dependencies belong to the project, not to your whole machine.

Why learn `uv` if `pip` already exists?

pip works. It is still a core part of the Python ecosystem. But in practice, a beginner using pip often ends up piecing together several separate commands and concepts:

python -m venv .venv
source .venv/bin/activate
pip install flet
pip freeze > requirements.txt

That approach is valid, but it can feel fragmented. You are manually creating the environment, manually activating it, manually installing packages, and often manually managing dependency output.

With uv, the workflow is more unified:

uv init --python 3.13 list-comp
cd list-comp
uv add "flet[all]"

That is one of the first places where uv feels better than a looser pip workflow. You are not just dropping packages somewhere into Python and hoping the setup stays clean. You are creating an actual project structure from the beginning. For students and junior developers, that is a better mental model.

So this is not really a matter of "uv good, pip bad." It is more accurate to say that pip is foundational, while uv provides a smoother modern workflow for starting and managing projects.

Step 1: Install `uv`

First, install uv from the command line.

curl -LsSf https://astral.sh/uv/install.sh | sh

After installation, check whether your terminal can find it:

which uv

If you do not see a result, your shell may not have picked up the updated PATH yet. On macOS, a quick fix is often to reload your shell profile instead of restarting your machine.

Try:

source ~/.profile
which uv

Depending on your shell, one of these may be the right file instead:

source ~/.zprofile
source ~/.zshrc
source ~/.bash_profile

The goal is simple: get uv installed and confirm that your terminal recognizes it.

Step 2: Initialize a new Python project

Now create a new project folder using Python 3.13:

uv init --python 3.13 list-comp
cd list-comp

This is already a better starting point than a loose install process. You are not just preparing to run Python code. You are establishing a project with structure, which is what you will need in team environments, internships, and real development work.

At this stage, you should have a new directory with starter files inside it.

Step 3: Add Flet to the project

What is Flet?

Flet is an open-source Python UI framework for building interactive web, desktop, and mobile apps using pure Python. No HTML/CSS/JavaScript required. It provides a set of UI “controls” based on Google’s Flutter widgets, so you can assemble modern interfaces—buttons, text, layouts, inputs—directly from Python code.

Why Flet?

Flet lets you build modern-looking, real UI apps early—without having to first learn a separate frontend stack. You get the motivation and feedback loop of seeing your code on-screen immediately, while still learning Python fundamentals that transfer everywhere.

Three key benefits:

One Python codebase that runs across platforms
Flet is designed for web, desktop, and mobile from the same app code, so what you build isn’t “just a toy GUI” that only works on your laptop.
You stay in Python (no HTML/CSS/JavaScript required)
You can build the entire app in Python, which keeps the learning curve focused on programming fundamentals instead of splitting attention across multiple languages and toolchains.
It teaches modern UI architecture (declarative + state)
Flet 1.0 adds a declarative approach inspired by React/SwiftUI-style thinking, so you’re learning concepts that scale to larger apps and map cleanly to what you’ll see later in industry frameworks.

To install Flet:

uv add "flet[all]"

This command adds Flet as a dependency and lets uv manage the environment and dependency metadata for you.

After that, inspect the directory:

ls -la

You should see a few important things, including:

a .venv directory
project metadata files
a lock file

That matters because it gives you two advantages immediately:

Isolation — your project has its own environment.
Repeatability — your dependency setup is tracked in a way that is easier to reproduce later.

That is a major reason to learn this workflow early. You are building habits that scale beyond toy examples.

Step 4: Activate the virtual environment

Even though uv handles a lot for you, it is still useful to understand how activation works.

Run:

source .venv/bin/activate

After activation, your shell prompt will usually show that the virtual environment is active.

This step reinforces an important Python habit: project dependencies belong to the project, not to your whole machine. That sounds small, but it prevents a lot of future confusion. It means your project stays self-contained, and you are less likely to break one project while working on another.

Step 5: Open the project and look at `main.py`

Open the folder in your editor of choice. You might use Cursor, VS Code, or something else. Inside the project, look for main.py.

You may find starter code there already. That is fine. But instead of leaving this as a basic script, we are going to turn it into a simple UI app with Flet.

This is where the tutorial becomes more interesting. You are moving from Python setup into something visual and demonstrable.

Step 6: Replace the starter code with a simple Flet app

Update main.py so it contains this:

import flet as ft


def main(page: ft.Page) -> None:
    page.add(
        ft.Text("Hello, I am Jesse", size=50, color="yellow")
    )


ft.app(main)

Let’s break that down.

`import flet as ft`

This imports Flet and gives it the alias ft, which is common in Flet examples and keeps the code shorter.

`def main(page: ft.Page) -> None:`

This defines the main function for your app. The page: ft.Page part is a type hint, which helps make the code easier to understand and can improve editor assistance. The -> None means the function does not return a value.

`page.add(...)`

This adds UI components to the page. In this case, there is just one component: a large text label.

`ft.app(main)`

This runs the Flet app using your main function.

The structure is simple, but it introduces a core idea: instead of printing output in the terminal, you are building a UI by adding elements to a page.

Step 7: Run the app

Now run the file:

flet run main.py

If everything is set up correctly, a desktop window should open and display your text.

That is the payoff. You used modern Python tooling to create a project, installed a UI framework cleanly, and launched a working graphical app. Even though it is small, it is already more compelling than another “Hello, World” printed to a terminal.

Step 8: Add an image asset

Now let’s make the app slightly more visual.

Create an assets directory:

mkdir assets

Place an image inside it, for example:

assets/cory_front.png

Then update main.py like this:

import flet as ft


def main(page: ft.Page) -> None:
    page.add(
        ft.Text("Hello, I am Jesse", size=50, color="yellow"),
        ft.Image("cory_front.png")
    )


ft.app(main, assets_dir="assets")

Now run the app again:

flet run main.py

You should now see both the text and the image.

This also introduces another practical concept: organizing project assets in a dedicated folder and explicitly telling the app where those assets live.

What this teaches beyond the commands

This tutorial is not just about getting one app window to open. It teaches a better development pattern.

You learned how to:

install a modern Python project tool
create a structured project directory
isolate dependencies in a virtual environment
install and manage packages more cleanly than an ad hoc pip workflow
build and run a simple UI app with Flet
add assets to the project

For beginners, that is a strong combination. Too many tutorials stay at the level of one-off terminal scripts. Those have value, but project-based workflows are what start to feel real. They also give you better material to talk about in interviews, on GitHub, and in portfolio discussions.

If you want more step-by-step tutorials like this, plus larger real-world Python projects, check out the free course: Industry Projects for Python

It is built to help learners go beyond basic syntax and start building projects they can actually explain, show, and use as part of their job preparation.

HowTo: Make a Pull Request on an Open Source Repo - Step by Step

Jesse Casman — Mon, 02 Mar 2026 16:22:50 +0000

If you're getting better at programming but still feel unsure about GitHub, learning how to make a pull request is one of the most useful practical skills you can build. It helps you contribute to team projects, understand real developer workflows, and show employers that you can work in a shared codebase, not just code alone.

For many beginners, GitHub feels confusing because the terminology arrives all at once: fork, clone, branch, commit, push, pull request. The good news is that the workflow is not complicated once you understand the order of operations. A pull request is simply the review step at the end of a process: you copy the code to your machine, make changes on a separate branch, push those changes to GitHub, and ask the project maintainers to review them.

This tutorial is aimed at computer science students, first-time contributors, and anyone preparing for internships who wants to build stronger team-development skills. The core workflow here is beginner-friendly and command-line based, which is exactly what makes it valuable: you learn what Git is actually doing instead of just clicking buttons.

All this information and more is covered in the free Industry Projects for Python course, which teaches beginner-friendly, real-world development skills with Git, GitHub, Python, and more: https://industry-python.thinkific.com/products/courses/industry-projects-with-python.

Why pull requests matter

When you work on code by yourself, it's easy to think programming is only about writing files and running programs. In teams, that is only part of the job. You also need to:

keep your changes isolated
explain what you changed
submit work for review
respond to feedback
avoid breaking the main branch

That is what pull requests are for. They are not just a GitHub feature, they are part of how teams collaborate safely.

This also makes pull requests useful in internship prep and interviews. If you can explain how you forked a repo, created a branch, committed changes, pushed them, and opened a pull request, you are already speaking the language of real-world software development.

Company repo vs open source repo

A useful place to start is the difference between a company repository workflow and an open source workflow.

In a company setting, if you already have write access to the repository, the process is simpler. You can clone the company repo directly, create a branch from main, make your changes, push your branch to that same repo, and open a pull request for review. The repo belongs to the organization, but you already have permission to work inside it.

In open source, that is usually not the case. You normally do not have write access to the original repository. So before you can contribute, you create your own copy of the project on GitHub. That copy is called a fork. Then you clone your fork to your computer, make changes there, and submit a pull request back to the original project.

That one distinction clears up a lot of beginner confusion.

The three-layer model

It helps to think in three layers:

Upstream repo: the original project owned by the maintainer or organization
Your fork: your personal copy of that project on GitHub
Local repo: the copy on your computer where you actually edit files

Once you understand those three layers, the rest becomes much easier.

Step 1: Install Git and make sure it works

You need:

Git
a GitHub account
a terminal (Windows Terminal or macOS Terminal)
a code editor such as VS Code

Any editor will do. The point is learning the workflow.

The workflow here uses the Git command line, which is worth learning early. After installing Git, verify it in the terminal by checking the version. The example setup uses Git, GitHub, Windows Terminal or macOS Terminal, VS Code, and a Quarto blog repository.

Step 2: Fork the repository

Go to the open source repository on GitHub and click Fork.

This creates a copy of the project under your own GitHub account. That matters because your fork is the version where you have write access. Without a fork, you usually cannot push changes to an open source project.

Step 3: Clone your fork, not the upstream repo

This is the most common beginner mistake.

You want to clone your fork, not the original upstream repository:

git clone https://github.com/your-username/repo-name.git
cd repo-name

If you clone the wrong repository, your later push may fail or go somewhere you did not intend.

Step 4: Create a branch before you change anything

Do not work directly on main. Create a feature branch first:

git checkout -b new-blog-post-on-pull-requests

This creates a new branch and switches you to it immediately.

Branching feels confusing at first, but the logic is simple: your branch is a safe workspace for your changes. It keeps your work isolated until it is ready for review.

You can confirm your current branch with:

git branch

Step 5: Make your changes locally

Now edit the files you want to change. Your change might be a documentation fix, a README improvement, a typo correction, or a small code update.

At this stage, everything is still local to your machine. You can use VS Code, Cursor, Notepad, or whatever editor you have available.

Step 6: Stage your changes

Once you have made your edits, stage the files you want to include in the commit:

git add .

Or, if you want to add only one file:

git add path/to/file

Then check the current state:

git status

This is one of the most important Git commands for beginners. Use it constantly. It shows what has changed and what Git is about to include.

Step 7: Commit with a clear message

A commit is a saved checkpoint in your branch history.

git commit -m "Start blog post on pull requests"

Your message should be short but useful. A reviewer should be able to tell what changed from the commit message alone.

If Git asks for your identity, configure it:

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

GitHub also offers a privacy-protecting email option if you do not want your personal email exposed in commit metadata.

Step 8: Check your remote before pushing

Before you upload anything, confirm where origin points:

git remote -v

In an open source workflow, origin should usually point to your fork. This is a simple check, but it prevents a lot of frustration.

Step 9: Push your branch to GitHub

Now push your branch:

git push origin new-blog-post-on-pull-requests

Depending on your setup, Git may open a browser window so you can authorize the push. That is normal. Once the push succeeds, your changes are on GitHub but only in your fork.

Step 10: Open the pull request

Go to your fork on GitHub. You should see a prompt like Compare & pull request.

Click it, then write a useful title and description. Do not treat this as an afterthought. The pull request is your explanation to the maintainer. Say what changed and why.

Also, do not open a pull request too early. If your work is incomplete, it creates extra friction for maintainers. Open a pull request when your changes are actually ready for review.

What happens after you open it?

This is where real collaboration starts.

As the contributor, you usually cannot merge the pull request yourself unless you are also a maintainer. Instead, the maintainer reviews it, tests it, and may comment or request changes. That back-and-forth is normal. It is not a sign that you failed—it is part of the process.

That review loop is exactly why this skill matters for students. It teaches you how development works in real teams:

you work in branches
you submit changes for review
you communicate clearly
you revise when needed
you avoid pushing unfinished work directly into the main codebase

Those are not optional “extra” skills. They are part of being employable as a developer.

Final takeaway

If you are still early in your GitHub journey, start small. You do not need to make a huge open source contribution on day one. A documentation fix, a blog post, or a minor improvement is enough to learn the workflow.

Once you can confidently fork a repo, clone your fork, create a branch, commit your changes, push to GitHub, and open a pull request, you are already building the kind of practical experience that helps with internships, interviews, and team-based software work.

If you want more beginner-friendly, job-focused tutorials like this, the full Industry Projects for Python course is free and built around real workflows that help students move from classroom coding to practical development: https://industry-python.thinkific.com/products/courses/industry-projects-with-python.

Python Iterables Explained Visually (Lists, Tuples & Sets)

Jesse Casman — Mon, 09 Feb 2026 16:08:57 +0000

Introduction

In this article, we break down Python’s core data types and show how they behave in real code: lists, tuples, sets, and strings.

You’ll learn:

The difference between mutable vs immutable objects
Why tuples can’t be changed but lists can
How tuple unpacking makes code cleaner and more readable
How sets remove duplicates automatically
How to use union, intersection, and difference on sets
How strings behave like immutable sequences
How type checking with mypy can catch data type mistakes
Why strings behave like immutable sequences
How type checking with mypy can catch data type mistakes

Full free course called Industry Projects with Python covers Python iterables and much more. Full code for each section is available for download.

Before we get into the “visual” part, here’s the quick mental model you should keep in your head:

LIST — A list is ordered, you can mutate it, and duplicates are fine.

✅ order
✅ mutable
✅ duplicates

TUPLE — A tuple keeps order and duplicates—but you can’t change items.

✅ order
❌ mutable
✅ duplicates

SET — A set drops duplicates and isn’t guaranteed to be ordered.

❌ order (no guarantee)
✅ mutable (you can add/remove items)
❌ duplicates (unique only)

In the code below, we build a “staff party” guest list to make the behavior obvious: you build collections of “people,” render them, then change the data structure and see what changes in output. This is explicitly aimed at “learning about iterables” and using Flet as the display layer.

How To Use

You’re implementing a small demo that:

Creates a handful of “items” (images like Corey/Jerry/Kristi/Matt/Susan).
Stores those items in a list, a tuple, and a set.
Iterates over each collection (because they’re iterables) and adds/renders each item.
Demonstrates the key behaviors:
- Lists allow item reassignment (mutation).
- Tuples reject item reassignment (“does not support item assignment”).
- Sets remove duplicates and don’t promise stable ordering.
- Set algebra (&, |, -) gives intersection/union/difference.

Key “moving parts” (classes / methods / operators)

Core Python concepts

list[T]: ordered, mutable, duplicates allowed.
tuple[T, ...]: ordered, immutable, duplicates allowed.
set[T]: unique elements, iteration order not guaranteed.
for x in iterable: iteration works across all three.

Set operations:

a & b (intersection): elements in both sets
a | b (union): elements in either set
a - b (difference): elements in a that are not in b

Flet concepts (for the “visual” angle)

ft.Image(...): creates a UI control you can render.
page.add(control): appends controls to the page.
ft.run(main): runs your app, calling main(page).

The “visualization” is simple on purpose: create a collection of UI controls, iterate it, and call page.add(...) for each item.

How to run it (practical workflow)

We use uv and run Flet locally. A typical setup looks like this:

Ensure you have Python installed.
Install dependencies with uv.
Put your images in an assets/ folder (or configure paths accordingly).
Run the Flet app locally.

Code Example

Below is a working example. The full code is available as a zip file in Chapter 13 of the course. It includes images.

If you have a folder of images (like assets/cory.png, assets/jerry.png, etc.), you can render the result by iterating a collection of ft.Image controls and adding them to the page.


import flet as ft

def main(page: ft.Page) -> None:
    # In the original demo, the "people" are images (iterables of controls).
    cory = ft.Image(src="cory.png", height=120)
    jerry = ft.Image(src="jerry.png", height=120)
    kristi = ft.Image(src="kristi.png", height=120)
    matt = ft.Image(src="matt.png", height=120)
    susan = ft.Image(src="susan.png", height=120)

    party_set: set[ft.Image] = {kristi, cory, jerry, kristi}   # duplicates collapse
    party_set2: set[ft.Image] = {matt, susan, jerry}

    # Show "difference" visually: who is only in party_set?
    difference_set: set[ft.Image] = party_set - party_set2

    page.add(ft.Text("Iterable Staff Party", size=32, weight=ft.FontWeight.BOLD))
    for person in difference_set:
        page.add(person)

ft.run(main)

Why this works as a learning tool:

You’re forced to iterate (for person in difference_set) because that’s how you “render many items” from any iterable.
You can see duplicates vanish when switching from list/tuple to set (the transcript explicitly calls out that only one “Kristi” remains).
You hit the tuple immutability wall immediately if you try to assign into a tuple (“does not support item assignment”).

That’s the core takeaway: pick the iterable based on the rules you need—mutation, ordering, and uniqueness—and then let iteration be the common “consumption interface” across all of them.

Full Industry for Python free course is available here: https://industry-python.thinkific.com/products/courses/industry-projects-with-python

New Python Courseware for Early-Career CS Students

Jesse Casman — Thu, 08 Jan 2026 23:08:20 +0000

Course Focus

Many students encounter computer science for the first time through command-line programs and abstract problem sets. While those foundations matter, they often fail to show how real software works—and why the concepts you’re learning actually matter.

This course bridges that gap.

Instead of learning Python in isolation, you’ll learn it through interactive, visual applications where your code immediately controls what appears on screen. This approach helps concepts “click” faster, builds confidence earlier, and mirrors how real applications are designed.

Most importantly, this course forces a transition many students never make: from writing small scripts → to producing industry-aligned projects you can meaningfully talk about in interviews.

Who this course is for

This course is designed for:

High-school students curious about computer science and software engineering
First- and second-year CS students preparing for internships or tougher coursework
Self-taught beginners who want structure and real projects
Students who feel comfortable with basics but struggle to connect concepts together
Anyone who wants to build something real without needing HTML, CSS, or JavaScript first

No prior experience with UI frameworks or AI is required. You’ll grow into those topics step by step.

Build Usable Apps You Can Modify

You won’t just read about programming concepts—you’ll use them in real applications.

You’ll build interactive Python apps where:

Characters (Cory, Susan, Jerry, and others) are modeled as Python objects
Lists and dictionaries generate UI elements dynamically
User input (buttons, dropdowns, sliders) controls application state
Event handlers connect interface actions to Python logic
Images, layouts, and real-time updates make your code visible and tangible

Through these projects, core Python ideas—classes, objects, lists, dictionaries, comprehensions, and control flow—become concrete instead of abstract.

Gain Internship-level skills

As the course progresses, you move beyond static interfaces into modern application patterns used in industry:

State management and event-driven logic
Asynchronous programming for responsive applications
Clean separation between UI, logic, and data
Deployment workflows from local development to the cloud

You’ll learn not just how things work, but why they’re structured the way they are—an essential skill for interviews.

Your edge: building a real AI application

In the later chapters, you’ll build an AI application that goes far beyond a “toy demo.”

You will:

Run large language models locally using Ollama
Build a chat interface with message history, roles, scrolling, and live updates
Implement async + streaming responses, the feature that makes modern AI apps feel real
Understand performance tradeoffs, prompt design, and system architecture

This is the kind of project that signals real understanding—not just tool usage.

What you’ll be able to demo and explain

By the end of the course, you’ll be able to confidently walk through:

A full-stack mental model: virtual environments → local servers → cloud deployment → HTTPS
Async and real-time patterns used in modern Python applications
Local LLM integration, streaming output, and UI updates
Architectural decisions and tradeoffs in clear, interview-ready language

Whether you’re preparing for your first internship, building a high-school portfolio, or strengthening your foundation before college CS courses, these skills transfer directly.

How to use this course

Follow along hands-on and build each project yourself
Experiment freely—breaking things is encouraged
Rebuild projects from scratch to strengthen understanding
Use the finished apps as portfolio pieces or interview demos

The course is free while the curriculum is being developed, and your feedback helps shape future modules.

Start the course here (free, full code included):
https://industry-python.thinkific.com/products/courses/industry-projects-with-python

Versioning Your Database with SQLAlchemy and Alembic: From Models to Safe Migrations

Jesse Casman — Wed, 19 Nov 2025 16:12:57 +0000

SQLAlchemy and Alembic give you a safer, more controlled way to evolve your schema over time. In the FastOpp Country Store project, that shows up when you do something simple but dangerous in real life: add a new column to an existing table in SQLite. Can you migrate your data without blowing everything up?

This tutorial follows the flow of the “FastOpp Country Store 05 – Add New Column to SQL Table” video. You will:

Change a SQLModel database model in FastOpp (SQLModel runs on top of SQLAlchemy)
Create and run database migrations (via Alembic under the hood)
Fix a real migration error from SQLite

My Ah-ha! Moment

I've been working with Django for a number of years on multiple projects for clients. I just got a breakthrough understanding working on a project called FastOpp. The big realization was this:

When using SQLAlchemy and Alembic, you first create a Python migration file, and only later, when you run alembic upgrade, does that file actually change your database schema.

At first, that feels like extra work. Why not just apply the changes directly?

Because that two-step process is the safety net.

alembic revision --autogenerate looks at your SQLAlchemy models versus the current database and writes a Python migration script.
At this point, nothing has happened to your database.
You get a chance to:
- Review and edit the migration.
- Commit it to git.
- Have others review it in a PR.
- Test it on dev/staging.

Only when you explicitly run something like:

alembic upgrade head

(or the FastOpp wrapper around that command) does Alembic connect to the database and apply those changes.

That separation—generate now, apply later—is what keeps accidental, destructive schema changes from landing silently in production. It is dramatically safer than systems that auto-migrate whenever the app starts and hope nothing catastrophic is in the diff.

Once this clicks, Alembic stops feeling like extra steps and starts looking like exactly what it is: version control for your schema.

What the FastOpp Video Actually Does

FastOpp is a FastAPI-based starter that gives you a Django-like experience for AI apps: admin panel, authentication, SQL database models and migrations, and Jinja2 templates with Tailwind/DaisyUI, all wired together in an opinionated structure.

In Part 5 of the Country Store series, the flow is roughly:

Start from a working FastOpp Country Store app using SQLite.
Add a new column to an existing SQLModel table (Food).
Use the FastOpp migration command (a thin wrapper around Alembic) to:

Create a migration.
Upgrade the database.
1. Hit a SQLite migration issue around nullability/defaults.
2. Edit the Alembic-generated migration file to fix the problem.

Step 1 – Add a New Column to the `Food` Model

The video works with a Food model representing items in the Country Store. The key step is adding a new price column to that table.

The resulting model looks like this:

import uuid
from sqlmodel import SQLModel, Field

class Food(SQLModel, table=True):
    __tablename__ = "foods"  # type: ignore

    id: uuid.UUID | None = Field(default_factory=uuid.uuid4, primary_key=True)
    name: str = Field(max_length=100, nullable=False)
    description: str | None = Field(default=None, nullable=True)
    image_url: str | None = Field(default=None, nullable=True)
    price: float = Field(default=0.0, nullable=False)

Important points:

table=True and __tablename__ = "foods" define the underlying table name.
Existing columns (id, name, description, image_url) are already in the database.
The new column is price: float = Field(default=0.0, nullable=False).

At this moment:

The Python model knows about price.
The SQLite database does not yet have a price column on foods.

That gap between “model” and “database” is exactly what the migration will fix.

Step 2 – Create a Migration (Alembic Revision)

FastOpp exposes a migration command that calls Alembic under the hood. Conceptually, it’s equivalent to:

alembic revision --autogenerate -m "add price to foods"

What this does:

Imports your SQLModel metadata (including Food).
Compares it to the existing SQLite schema.
Writes a new migration script in your migrations/alembic/versions directory.

A simplified version of the generated migration might look like this:

from alembic import op
import sqlalchemy as sa

def upgrade() -> None:
    op.add_column(
        "foods",
        sa.Column("price", sa.Float(), nullable=False),
    )


def downgrade() -> None:
    op.drop_column("foods", "price")

This is only a plan. The database still does not have the price column. You are in the safe stage where you can:

Inspect the migration.
Adjust nullability or defaults.
Commit it to git.

Step 3 – Run the Migration and Handle SQLite Constraints

Next, run the upgrade. In raw Alembic:

alembic upgrade head

In FastOpp, we use a wrapper command via oppman.py, but the end result is the same: Alembic executes the upgrade() function against your SQLite database.

Here is where SQLite can cause trouble. Adding a non-nullable column (nullable=False) to a table that already has rows is a classic problem:

SQLite needs a value for price on every existing row.
If the migration doesn’t specify a default at the DB level (server_default), SQLite tries to use NULL.
NULL contradicts NOT NULL, and you get an error similar to:

sqlite3.OperationalError: Cannot add a NOT NULL column with default value NULL

Even though the SQLModel field has default=0.0, Alembic’s autogenerate may not automatically turn that into a proper server_default on the database column. So you end up with:

sa.Column("price", sa.Float(), nullable=False)

and no default on the DB side.

This is exactly the kind of mismatch the video walks through: the application-level default and the database-level constraints are not fully aligned, and SQLite forces you to resolve it.

Step 4 – Fix the Migration Script for SQLite

The correct place to fix this is the migration file, not manual SQL pokes to your database.

Option A – Allow `NULL` Temporarily

For a demo app like Country Store, the easiest fix is to relax the constraint:

def upgrade() -> None:
    op.add_column(
        "foods",
        sa.Column("price", sa.Float(), nullable=True),
    )

SQLite can now add the price column and set NULL on all existing rows.

Your application code can treat None as “unknown price” or fall back to 0.0 at the Python layer. This keeps the migration simple and safe for a tutorial.

Option B – Set a Database Default

If you really want NOT NULL at the database level, then you need to explicitly tell SQLite what to put into price for old rows:

def upgrade() -> None:
    op.add_column(
        "foods",
        sa.Column(
            "price",
            sa.Float(),
            nullable=False,
            server_default="0.0",
        ),
    )

Now SQLite:

Adds the price column.
Fills 0.0 for every existing row.
Enforces NOT NULL going forward.

The core idea:

SQLModel’s default=0.0 is not enough by itself.
You must encode your intention into the migration so SQLite knows what to do with existing data.

Step 5 – Re-run the Migration

After editing the migration file:

alembic upgrade head

(or the FastOpp wrapper)

This time the migration should succeed:

The foods table gains a price column.
Existing rows either have NULL or 0.0, depending on your choice.
Alembic records that the migration has been applied.

Anyone else working on the FastOpp project just has to pull the code and run the same upgrade command to get the same schema.

Why This Flow Matters

This one change to the Food model (price added to foods) quietly demonstrates several important habits:

Change the model first.
The SQLModel definition is your desired end state.
Generate and review a migration.
Let Alembic autogenerate the migration, then edit it so SQLite’s constraints and your data model actually match.
Fix problems in code, not with ad-hoc SQL.
When SQLite complains about nullability or defaults, the answer is to adjust the migration script and run it again.
Wire the change through to the UI.
Jinja2 templates, with variable interpolation and simple helpers like .split(), give you a clean way to expose new columns.

Once you internalize this pattern, adding a new column like price to foods stops being a risk and becomes a predictable, repeatable process—exactly what you want in a real project.

FastOpp: A Student-Friendly Starter for AI Web Apps

Jesse Casman — Wed, 17 Sep 2025 05:30:27 +0000

If you’re a student or novice developer curious about building AI web applications, FastOpp is worth a look. It's a well-scaffolded, beginner-friendly opinionated open source technology stack for building AI web apps. It bridges the gap between learning frameworks and real-world AI-first apps. You can explore the live site here: https://fastopp-site.fly.dev/.

Example demo site, extending functionality, like you can do: https://fastopp-site.fly.dev/example

Mentorship & Support Offered for Students:

Weekly video meetings with experienced mentor
Structured learning path with tutorials and GitHub issues
Professional reference from Jesse Casman, President of Oppkey, a Silicon Valley-based Developer Relations firm (available after minimum 3 months of contributions)
Open source contribution experience that can be added to your resume
Git and GitHub experience including push, pull requests, and code reviews

What is FastOpp?

FastOpp is an open source starter package based on FastAPI built for creating AI web applications more easily. It offers ready-built components—admin panels, templating, authentication, database migrations—packaged in an opinion-driven structure so you can skip boilerplate and focus on building features.

Key features:

Admin panel like Django, with role-based authentication.

SQL database models and migrations inspired by Django’s model structure.

HTML templates (Jinja2) with modern UI (Tailwind, DaisyUI, AlpineJS, HTMX) so you can build simple but decent UIs without heavy JavaScript.

API endpoints with auto-generated documentation (FastAPI style) so you can later add React, Flutter or other frontends.

Management tools:

• oppman.py for core commands (server start/stop, migrations, backups)
• oppdemo.py for switching between demo/full mode vs minimal mode, handling sample/demo data

Who is FastOpp For?

FastOpp targets students and junior devs who:

Know Python and want to build web apps with AI/LLMs.
Are more comfortable with backend logic in Python than heavy JavaScript frontends.
Prefer templates and integrated UI over writing a bunch of frontend code.
May have used Django or Flask and found async / LLM integration hard. FastOpp helps with that.
It is not optimized for production-grade, high-traffic applications. If you need enterprise-level security, scaling, or complex frontends you might need more tools. But for learning, MVPs, hackathons, or portfolio pieces, it’s strong.

What You’ll Learn Through FastOpp

You’ll gain practical experience with a real stack of tools used in today’s developer environments. This means you won’t just learn syntax—you’ll learn how modern apps are put together and deployed.

Core Technologies

FastAPI: an async Python web framework with automatic interactive documentation.

SQLite / PostgreSQL: relational databases with migrations for structured data storage.

Jinja2 Templates: server-side rendering for web pages.

Tailwind CSS + DaisyUI: modern, utility-first styling and ready-made UI components.

HTMX + Alpine.js: lightweight JavaScript helpers for adding interactivity without full SPA complexity.

Authentication: role-based login and access control.

Management Scripts: Python commands (oppman.py, oppdemo.py) to handle server tasks, migrations, and demo mode.

Demonstration of Modern Web Technologies and Development Tools

By using FastOpp you’ll also work with the tools and workflows expected in professional settings:

Environment Variables: manage secrets and settings securely.
Migrations: database versioning to evolve schemas without breaking data.
Static and Dynamic Files: organize assets and serve them correctly in apps.
Admin Interfaces: built-in panels for managing users and content.
API Endpoints + Docs: every app automatically generates docs for testing and integration.
LLM Integration: practice connecting to and using large language models through APIs.
Deployment Concepts: running apps locally, testing in demo mode, and preparing for cloud platforms like Fly.io.

These aren’t toy examples—they’re the same concepts you’ll use when moving into internships, jobs, or contributing to other open source projects.

Why You Should Try It

You’ll get hands-on experience building AI web apps with a scaffolded yet flexible base.

You’ll learn migration workflows, authentication, templating, LLM integration. Good skills on resume.

Faster prototype → you can build projects to share or show in portfolio.

You can see inside another’s project architecture: how things like management scripts, sample/demo data, file uploads, static vs dynamic parts are organized.

Conclusion

FastOpp is a well-scaffolded, beginner-friendly opinionated open source technology stack for building AI web apps. It doesn’t hide complexity, but it reduces boilerplate so you can focus on what you care about: prototypes, features, learning.

If you want to build apps, learn web + AI integration, or boost your portfolio, contributing to or using FastOpp is a good move.