Allow embedding of script lock files

[zanieb]

e.g., see #6318 (comment)

We added support for script lock files, but they're separate from the script. This makes them easier to detect and operate on. However, for fully reproducible scripts, it may be nice to embed a lockfile in the script itself.

[marengaz]

agree with charlie's comment that "embedded lockfile is somewhat impractical"
perhaps a suitable compromise would be a flag to enforce the use with a lock file?

# /// script
# requires-python = ">=3.12"
# dependencies = [
#     "requests<3",
#     "rich",
# ]
# enforce-lock-file = true
# ///

where uv run --script would throw a helpful error if the lock file wasn't resolvable by usual logic?

[notatallshaw]

#6318 (comment)

I personally think the embedded lockfile is somewhat impractical -- just way too big. But we can probably support it.

Depends on the use case, for general development environments I agree.

But I can imagine situations where you'd like to send a file to someone outside traditional development, such as sending files to a semi technical user, or academic or other organizations where development best practices are not great and they email or copy files around. In cases like these there's a huge convenience to having just one file, not keeping two together and in sync.

[martimlobao]

@marengaz The usecase I'm envisioning is more what @notatallshaw is getting at: I don't want the script to fail if there isn't a lockfile, I want to be able to run the script reproducibly as a standalone executable.

I can sympathize with the argument that an inline lockfile might be impractical in some cases though. At the risk of proposing yet another option, perhaps a --inline flag might be a good alternative to allow for each behavior depending on the use case.

[charliermarsh]

It seems fine to support this as an opt-in thing.