Pre-PEP: Locking a PEP 723 single-file script

My experiences with people passing around single file scripts is that they become internal tools people rely upon without the same level of scrutiny applied to them, and that over time, they do become problematic, especially when the original author is no longer available to support the person it was passed to, or it is passed to a non-development team. While I can’t guarantee it will be more of a problem with locking, I strongly believe that the prior experiences of packaging and hard pinning versions will interact with this in unpleasant ways by nature of how people treat tools like this.

I also think it may interact poorly with people’s existing expectations for python scripts[1] On linux for example, many people are used to many of their python dependencies automatically being updated when not explicitly using a venv isolating from system python.[2] With unpinned versions and single file script dependencies, this was sort of still transparently happening for users, just with the tool managing per-app venvs.

I think in many ways, the problem is less the tools themselves and more the way people are already using these tools, intersecting with concerns about who has to be aware of what for security features to work. Even if people don’t have any of these intersecting concerns, I think reviewing blocks like this in scripts is going to significantly contribute to security fatigue.

I’ll retract that. My thoughts here were along the above, but the same person that isn’t going to know why this is a problem also isn’t going to know to run something to update the block or know to delete that block. It’s more inherent to the ideas of treating loose scripts this way in the first place, so this doesn’t even help with what I would want to avoid.


I’m trying to think about this from a perspective of “How do we make the easiest way of using this, also the best way”, and I’m having trouble envisioning this as better than distributing packages with a console scripts entrypoint that are already supported by tools like pipx and uvx, but then also come with an update distribution mechanism.

I’m also skeptical of the single-file deployments as a use case here, It appears to be the only one that benefits from actual locking in this manner. I have questions as to why other tools and options here are insufficient, but this particular workflow is not something I have personal experience with.


  1. I don’t think all expectations here are good expectations, but that doesn’t make them not expectations I’ve seen people have before. ↩︎

  2. I’m not looking to reignite a war on distribution packaging vs per-app venvs, there are tradeoffs and differing use cases, and neither is perfect ↩︎

4 Likes