Explore the power of Git Town, a tool that enhances Git workflows and helps streamline code contributions. Discover PEP 751, a groundbreaking file format for managing Python dependencies with improved reproducibility. Delve into automated tools that boost team collaboration and package management. Learn about version control techniques, including the 'blame' feature and squashing commits for cleaner project history. Finally, uncover how UV and PEP 723 simplify deploying Python scripts, plus amusing anecdotes from the Python community.
36:31
forum Ask episode
web_stories AI Snips
view_agenda Chapters
auto_awesome Transcript
info_circle Episode notes
volunteer_activism ADVICE
Streamline Git Workflow with Git Town
Use Git Town to streamline your Git workflow with high-level commands for common actions like creating, syncing, and shipping feature branches.
Simplify complex Git operations and manage multiple branches effectively within your existing CLI or GUI.
insights INSIGHT
Standardized Lock Files with PEP 751
PEP 751 introduces a standardized lock file format for Python called pylock.toml.
This format improves dependency management and reproducibility by providing a shared format for tools like pip, poetry, and uv.
volunteer_activism ADVICE
Analyze Project Contributions with git-who
Use git-who to determine project contribution levels.
This command summarizes commits and changes by author, offering a broader view than line-by-line blame.
Get the Snipd Podcast app to discover more snips from this episode
Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am PT. Older video versions available there too.
Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it.
Michael #1:Git Town solves the problem that using the Git CLI correctly
Git Town is a reusable implementation of Git workflows for common usage scenarios like contributing to a centralized code repository on platforms like GitHub, GitLab, or Gitea.
Think of Git Town as your Bash scripts for Git, but fully engineered with rock-solid support for many use cases, edge cases, and error conditions.
Keep using Git the way you do now, but with extra commands to create various branch types, keep them in sync, compress, review, and ship them efficiently.
This means Python now has a lock file standard that can act as an export target for tools that can create some sort of lock file. And for some tools the format can act as their primary lock file format as well instead of some proprietary format.”
File name: pylock.toml or at least something that starts with pylock and ends with .toml
It’s exciting to see the start of a standardized lock file
git-who is a command-line tool for answering that eternal question: Who wrote this code?!
Unlike git blame, which can tell you who wrote a line of code, git-who tells you the people responsible for entire components or subsystems in a codebase.
You can think of git-who sort of like git blame but for file trees rather than individual files.
And watchgha- Live display of current GitHub action runs by Ned Batchelder
Been using mdformat on some upcoming projects including the almost done Talk Python in Production book. Command I like is mdformat --number --wrap no ./
uv tool install --with is indeed the pipx inject equivalent, but requires multiple --with's:
As a fellow uv enthusiast, I was still holding out for a use case that uv hasn't solved. However, after last week's episode, you guys finally convinced me to switch over fully, so I figured I'd explain the use case and how I'm working around uv's limitations.
I maintain a python library supported across multiple python versions and occasionally need to deal with bugs specific to a python version. Because of that, I have multiple virtualenvs for one project. E.g., mylib38 (for python 3.8), mylib313 (for python 3.13), etc. I don't want a bunch of .venv directories littering my project dir.
For this, pyenv was fantastic. You could create the venv with pyenv virtualenv 3.13.2 mylib313, then either activate the venv with pyenv activate mylib313 and create a .python-version file containing mylib313 so I never had to manually activate the env I want to use by default on that project.
uv doesn't have a great solution for this use case, but I switched to a workflow that works well enough for me:
Define my own central location for venvs. For me that's ~/v
Create venvs with something like uv venv --python 3.13 ~/v/mylib313
Add a simple function to my bashrc:
`workon() { source ~/v/$1/bin/activate } \ so now I can run \workon mylib313orworkon mylib38when I need to work in a specific environment. uv's.python-version` support works much differently than pyenv's, and that lack of support is my biggest frustration with this approach, but I am willing to live without it.
Do you Firefox but not Zen? You can now make pure Firefox more like Zen’s / Arc’s layout.
Python Bytes 
