Zanie Blue
Zanie Blue
> Adopting inline script metadata is still very difficult as not many of my of my users use uv or a 723-compatible runner. External lock files would support a wider...
> If we dumped the lock file contents into some tool.uv.xxx property there... The only problem with this is that the lockfile is quite long, so we probably don't want...
`uv run --with-requirements requirements.txt script.py` probably already works, though I'm honestly not sure what happens if there's PEP 723 metadata in there.
I'm sort of all for just having a way to write this metadata at the bottom. We're sort of in a tough place w.r.t. the specification though. It says things...
I think rewriting the `dependencies` section would be too detrimental to the user experience. There are caveats to `exclude-newer`, like private indexes and proxies may not include publish times, but...
I'm into that interface, yeah. What about `uv add --script` — won't create?
There's also a case for putting them in `/.uv/locks` or `$(dirname )/.uv/` so they don't clutter your directories. Then we could avoid the awkward leading `.` (which I think is...
It was easier to put it elsewhere — but I'm generally in favor of support an embedded lockfile too.
Let's discuss further in #11064
Well, we should support this with `uv add -r requirements.txt` but that doesn't propagate `tool.uv.sources` like it should — we'll fix that and document it. e.g. ``` ❯ uv init...