> I don't want to be forced into foregrounding the project.
The advantage of being forced to do this is other people (including yourself on a new laptop) can clone your project, run uv install and get working. It's the death of "works on my machine" and "well it'll take them a couple of weeks to properly get up and running".
> The advantage of being forced to do this is other people (including yourself on a new laptop) can clone your project
I know this might be a strange idea on HN, but tons of people writing code in Python, who need access to PyPI packages to do what they're doing, have no intention whatsoever of providing a clonable project to others, or sharing it in any other way, or indeed expecting anyone else on the planet to run the code.
Sure, that's fine. I'm saying I just won't get to that stage until later.
A “project" is largely a way of storing the definition of the state of a environment in a config file (pyproject.toml). It does a bit more, but you can basically ignore that initially.
It takes a couple of seconds to setup, and then you just use uv add instead of (uv) pip install to add things to the environment, and the project file is kept in sync with the state of the environment. I'm not really understanding what it is for the workflow you describe that you expect a tool to do that uv isn’t providing?
Just professional software engineering practices.