Topics covered in this episode:
Git Town solves the problem that using the Git CLI correctly
PEP 751 – A file format to record Python dependencies for installation reproducibility
git-who and watchgha
Share Python Scripts Like a Pro: uv and PEP 723 for Easy Deployment
Extras
Joke
Watch on YouTube
About the show
Sponsored by Posit Package Manager: pythonbytes.fm/ppm
Connect with the hosts
Michael: @
[email protected] / @mkennedy.codes (bsky)
Brian: @
[email protected] / @brianokken.bsky.social
Show: @
[email protected] / @pythonbytes.fm (bsky)
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.
Basic workflow
Commands to create, work on, and ship features.
git town hack - create a new feature branch
git town sync - update the current branch with all ongoing changes
git town switch - switch between branches visually
git town propose - propose to ship a branch
git town ship - deliver a completed feature branch
Additional workflow commands
Commands to deal with edge cases.
git town delete - delete a feature branch
git town rename - rename a branch
git town repo - view the Git repository in the browser
Brian #2: PEP 751 – A file format to record Python dependencies for installation reproducibility
Accepted
From Brett Cannon
“PEP 751 has been accepted!
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
Michael #3: git-who and watchgha
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
Brian #4: Share Python Scripts Like a Pro: uv and PEP 723 for Easy Deployment
Dave Johnson
Nice full tutorial discussing single file Python scripts using uv with external dependencies
Starting with a script with dependencies.
Using uv add --script [HTML_REMOVED] [HTML_REMOVED] to add a /// script block to the top
Using uv run
Adding #!/usr/bin/env -S uv run --script shebang
Even some Windows advice
Extras
Brian:
April 1 pranks done well
BREAKING: Guido van Rossum Returns as Python’s BDFL
including
Brett Cannon noted as “Famous Python Quotationist”
Guido taking credit for “I came for the language but I stayed for the community”
which was from Brett
then Brett’s title of “Famous Python Quotationist” is crossed out.
Barry Warsaw asking Guido about releasing Python 2.8
Barry is the FLUFL, “Friendly Language Uncle For Life “
Mariatta can’t get Guido to respond in chat until she addresses him as “my lord”.
“… becoming one with whitespace.”
“Indentation is Enlightenment”
Upcoming new keyword: maybe
Like “if” but more Pythonic
as in Maybe: print("Python The Documentary - Coming This Summer!")
I’m really hoping there is a documentary
April 1 pranks done poorly
Note: pytest-repeat works fine with Python 3.14, and never had any problems
If you have to explain the joke, maybe it’s not funny.
The explanation
pi, an irrational number, as in it cannot be expressed by a ratio of two integers, starts with 3.14159 and then keeps going, and never repeats.
Python 3.14 is in alpha and people could be testing with it for packages
Test & Code is doing a series on pytest plugins
pytest-repeat is a pytest plugin, and it happened to not have any tests for 3.14 yet.
Now the “joke”.
I pretended that I had tried pytest-repeat with Python 3.14 and it didn’t work.
Test & Code: Python 3.14 won't repeat with pytest-repeat
Thus, Python 3.14 won’t repeat.
Also I mentioned that there was no “rational” explanation.
And pi is an irrational number.
Michael:
pysqlscribe v0.5.0 has the “parse create scripts” feature I suggested!
Markdown follow up
Prettier to format Markdown via Hugo
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:
pipx inject mdformat mdformat-gfm mdformat-frontmatter mdformat-footnote mdformat-gfm-alerts
uv tool install mdformat --with mdformat-gfm --with mdformat-frontmatter --with mdformat-footnote --with mdformat-gfm-alerts
uv follow up
From James Falcon
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.
Joke: So here it will stay
See the follow up thread too!
Also: Guido as Lord Python via Nick Muoh
USA