I'm a bit confused, `uv run --with $package main --help` should do what you say with very little overhead. We won't reinstall it every time, `--with` environments are stored in the cache and retained. Even if the environment is cached, the dependency is cached and installing from the cache is very fast (<200ms for sure).
replyPlease feel free to open a reproduction with details and we can look into it.
(I work on uv)
I think you want `uv tool install` and `uv tool upgrade` for that. But also: please file an issue, because it sounds like the kind of papercut we could address somewhat easily!
replyI was thinking the same. Furthermore you have the `-e` flag which lets you install the tool in editable mode, meaning that they are run directly and thus any edit you make will be present when you use the tool.
replyThe only thing that you need to be aware of is that if you add another package or change it's version you need to reinstall the tool. I would suggest first removing it with `uv tool uninstall $NAME` and then reinstall it.
Could it be a code artifact thing? I’ll see about opening an issue soon enough
replyYou can also define required dependencies in a doc block at the top of the file and then just “uv run main” and it will automatically install and cache any dependencies and run. https://docs.astral.sh/uv/guides/scripts/
reply> uvx or uv tool weren’t much better as that posed new problems where a user wouldn’t get upgrades.
replyCouldn't the user just run `uv tool upgrade <tool_name>`?
That command takes 6 seconds I believe as well if I remember correctly. And likely there isn’t a ton of churn on the script. So having it make a new venv each time is kind of annoying. I was trying to aim for a good balance of fast and developer experience.
replyBasically if there’s an upgrade everyone needs to be using the most recent version, I didn’t want to rely on a pr dance to pin versions, and I also didn’t want to rely on everyone running a command when there ’s a change
You might wanna check out https://copier.readthedocs.io/en/stable/
replyDunno if it's your exact use case but it's been amazing for keeping a polyrepo microservice ecosystem in sync.
I’m familiar! I recently built something with projen. Projen is quite cool because you can mark templates as “managed,” which means they’re read only in the repo. Establishes a contract of “any edit to this file will be lost”
reply