Sort of compelling. I'm not sure it's a project setting, i.e., it seems more like a user setting? I'd be confused if some repository I cloned wouldn't let me activate the environment.

I like this personally. Took a look through the code and might try to work it in the morning (so long as my 9 month old doesn’t have other plans) Never written more than a small coding challenge in rust, but I’d permanently have this setting on so it feels like a nice quality of life bump which is good motivation to learn. If I do have the time, I’ll probably put up a draft pretty quickly in the morning to make sure I’m not entirely off base.

Does uv have a concept of settings that are global/user only but not local/project? An example doesn’t come to mind right now. Personally, there are quite a few options I’d find odd to be set at the project level that (as far as I can tell) uv would have no problem with you configuring in pyproject.toml. My thought would be to add an override flag to uv venv to flip the scripts back on if a dev really wanted them in a project that choose to disable them by default.

I'd be confused if some repository I cloned wouldn't let me activate the environment.

yeah I know, I'd still want to enforce that to my users :D

but I'd be satisfied with just per-user setting.

@zanieb Please let me know if I'm off base with the change in that PR. Like I said, first time in a large Rust project so I won't be offended if you tell me I broke something.

Looking at adding activatable (default true) to the installer options for the next step. Would that make sense to you?