Enhancing Package Management and Git Insights

• 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

About the show

Sponsored by Posit Package Manager: pythonbytes.fm/ppm

Connect with the hosts

• Michael: @mkennedy@fosstodon.org / @mkennedy.codes (bsky)
• Brian: @brianokken@fosstodon.org / @brianokken.bsky.social
• Show: @pythonbytes@fosstodon.org / @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