Split from thread https://pantsbuild.slack.com/archives/C046T6T9U/p1633551296368500 @happy-kitchen-89482 I’ve been thinking about a similar use case (https://github.com/pantsbuild/pants/issues/11812#issuecomment-811053105) Perhaps that approach would work for hot-reload support of uvicorn, Django and others too.. ? I could look into it a bit, if it is a feasible approach for you? (That is, creating a source dist where the sources are linked rather than copied over from the workspace so we can create a venv that stays up to date with changes in the workspace as they happen.) Only need to re-run

package

in case of changed dependencies/set of sources and the like.)

The script will need to be set with the reload flag on uvicorn in the case anyway, right? It will not terminate and spawn, right?

Interesting, but not sure that's the approach we want to take. Pants itself already watches the filesystem for changes, and it has a much more accurate view on when to reload. For example, the Django dev server won't reload when you edit templates or .proto files, but Pants could.

so you want to kill the process?

But today you can do, e.g.,

./pants --changed-since-main --loop test

and it'll rerun the relevant tests as the filesystem changes. Allowing

./pants --loop run path/to/manage.py

seems like an obvious extension of that functionality, that we should support.

so the

script

will not use its own reload system e.g.

uvicorn --reload

will not be used, just

uvicorn

, giving the power to pants to restart the process. Is there a thought about the killing process already?

Exactly - you wouldn't use the Django or uvicorn reloading feature, you'd let Pants do it (because in a non-trivial situation it can do it better)

yea, i’ll pick up https://github.com/pantsbuild/pants/issues/9462 later today.