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

[h-vetinari]

Thanks for the response.

@pf_moore

@h-vetinari

Having different types (/// script & /// lock) at different ends (top & bottom) makes sense, and even other types /// foo can be allowed to exist elsewhere in the file, but beyond that, I don’t see what the flexibility you mention buys us, except headaches.

The behaviour you describe here is all I covered in my comment, so I’m not sure if we’re agreeing or disagreeing here…?

Great if we agree already! My initial response had been to “I’ll object strongly to any attempt to remove that flexibility”. I think it’s fine to keep flexibility, in the sense of not constraining reasonable usage patterns without any rationale. But for the /// lock sections, there is a clear rationale to curtail that flexibility somewhat, in the sense that “hiding” executable in/after large comments does not become an attack vector.

So I think we agree that flexibility is good (e.g. introducing other types of blocks can be introduced as necessary). We may also agree that if lockfiles get added to scripts, they should be at the end.

@pf_moore

I will note that PEP 723 was accepted in preference to PEP 722 at least in part because it offered a more general mechanism. Removing that generality “because we don’t currently need it” feels to me like it’s missing the point…

Unusually for me in these discussions, I have a very concrete memory of (and to some degree, participation in) this; to me the distinguishing factor in favour of PEP 723 was hewing as closely as possible to the established pyproject.toml style of dependency-specification, rather than inventing another scheme to do so. The former naturally includes a degree of flexibility – tools can leverage existing patterns to add something like

# [tool.uv]
# exclude-newer = "2023-01-10T00:00:00Z"

and no spec or implementation needs to be changed for this to make sense or be compatible –, but that doesn’t mean that flexibility in and of itself was the overriding principle.

@pf_moore

As far as requiring the lock section to be at the end of the file, how about those editor variable blocks that Emacs users like to include in their files? Those go at the end of the file, I believe. Is it OK for those to go after the lock section?

To be clear, I don’t have any problem with a strong recommendation that lock sections go at the end of the file. That’s both reasonable and acceptable under the current spec.

I think the key point is avoiding executable code creeping in after large lockfile blocks. Anything that’s just comments could still be allowed. I guess I could live with a “strong recommendation”, though preferably my suggestion would be: “your locked script is the concatenation of foo.py plus its lockfile”.

That might actually be a neat approach to square the circle with the whole sidecar discussion. In that way, users could choose if they want to have

foo.py       # unchanged
foo.py.lock  # sidecar
# or
foo.py  # concatenation of original + its lockfile (wrapped into `/// lock` block)

and both variants would be trivially transformable into the other. Normally we prefer “one and only one way to do it”, but as long as the two instances are kept interconvertible^[1], this wouldn’t actually be a large implementation burden IMO, but would provide users with a meaningful choice that’s hard to dictate for everyone (i.e. whether keeping everything in one file is more important, or whether they want to avoid large blobs in their scripts).

---

1. something that would clearly favour keeping the /// lock section at the end to simplify this process ↩︎