Moving on

This page is for students who are finishing up with Making With Code, and thinking about what's next. mwc has been managing some details of the projects we have been working on, so that you could focus on learning the core knowledge, skills, and ideas. This page explains the details we have been hiding, for when you're ready to work on projects of your own. We are not trying to teach you all about these tools for now (that would be a lot!), just letting you know what they are so you can learn more about them when you are ready.

Version Control

You fetch your assignments with mwc update and turn them in with mwc submit. These commands are simplifications of the underlying tool, git, which is the version control tool most professional software developers use. mwc submit runs git's commit and push, and mwc update runs a pull. Git can do a lot more than that (branching, diffing, resolving conflicts between two people's changes),

Your work in this course has been synced with a version control server at git.makingwithcode.org. When you are ready to start your own projects, you will probably want to use GitHub.

Your Code Is Yours to Keep

Everything you wrote in this course belongs to you, not your school or your teacher. It's worth holding onto as a reference, a portfolio, or a starting point for a future project. But your account on git.makingwithcode.org won't last forever: once the course ends, you'll lose access to that server, and mwc submit/mwc update will stop being able to sync anything.

If you want to keep syncing a project after that — backing it up, sharing it, continuing to work on it — you can point it at a different git host instead, like GitHub. Every project folder already has a name for the server it talks to, origin; moving a project means creating a new, empty repository on GitHub and repointing origin at it. For one module:

cd path/to/lab_whatever
git remote set-url origin https://github.com/<your-github-username>/<repo-name>.git
git push -u origin main

While you're there, add yourself as an author in pyproject.toml — it's your project now, and this is the standard place a Python project records who wrote it:

authors = [{ name = "Your Name", email = "you@example.com" }]

After that, ordinary git push and git pull (not mwc submit/mwc update, which only know how to talk to the MWC server) will keep that project synced with GitHub. You'd repeat this — one git remote set-url and git push — for each project you want to carry forward.

Python Projects

Every one of your labs, problem sets, and projects in this course has been structured as a Python project, Three tools work together to make Python "just work" in every project folder:

• pyproject.toml is a file in every lab folder listing the Python packages that lab needs. When Chris updates a lab, this list is sometimes what changes.
• uv is a Python package manager. Whenever you get a new lab or its dependencies change, mwc runs uv venv to create an isolated folder of installed packages (a virtual environment, .venv) and uv sync to install exactly what pyproject.toml lists into it.
• direnv is what turns that environment on and off automatically. Each lab folder has a .envrc file that activates its .venv; direnv runs that file the instant you cd into the folder in a terminal, and deactivates it when you leave.

Put together: pyproject.toml says what a project needs, uv installs it into a project-specific .venv, and direnv switches that .venv on as you enter a directory. Run ls -a in any of your project directories to see all the files, even the hidden files. This will let you inspect how the pieces work together.

Tools that aren't Python packages

A few labs need software that isn't a Python package at all — ImageMagick for image processing, pandoc for converting documents, poppler for reading text out of PDFs, ollama for running a language model on your own computer. pyproject.toml and uv only manage Python packages, so these don't go through them. Instead, mwc setup installed each one once, directly on your computer, the same way you'd install any other application — using Homebrew on Mac, or apt on Linux and WSL.

Starting a project of your own

Outside an mwc-managed folder — a personal project, something after this course — you'll set all of this up yourself:

• uv init myproject starts a new folder with its own pyproject.toml.
• uv add <package> (e.g. uv add requests) adds a dependency and installs it.
• Write a .envrc containing source .venv/bin/activate and run direnv allow once, so the environment turns on automatically when you enter the folder — or just run source .venv/bin/activate yourself each time.
• git init, then git add and git commit as you go, and git push to a host like GitHub if you want a backup or want to share it.
• If your project needs a non-Python tool, install it yourself with brew install <name> (Mac) or sudo apt install <name> (Linux/WSL) — the same way mwc setup did for you.

It's the same handful of ideas you've been relying on all course — dependencies, environment, activation, saving your work — just with the automation switched off, so you're the one running each step.