Split from thread <https://pantsbuild.slack.com/ar...
# general
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
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?
👍 1
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.
Pants already uses this with
to rerun things on filesystem changes in an accurate and fine-grained way
So the only missing piece is that
doesn't kill a
process on filesystem changes, and that is hopefully not hard to change
Although I will defer to @witty-crayon-22786 who knows more about how that works than I do
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.
Yes, that would be the idea
so the
will not use its own reload system e.g.
uvicorn --reload
will not be used, just
, 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)
Yes, I believe @witty-crayon-22786 knows how to get that done and has mentioned doing it soon
🙌 1
👍 1
yea, i’ll pick up https://github.com/pantsbuild/pants/issues/9462 later today.
👍 2
sketched this out in: https://github.com/pantsbuild/pants/issues/9462#issuecomment-938197286 … basically, this should be fairly strightforward to do, but i think that we won’t want to restart user code unless it has opted in via something like
pex_binary(.., interruptible=True)
… feedback welcome!
having said that: using
would still be compatible with a goal that produced a venv somewhere, if someone wants to write a goal to do that… then you could do something like
./pants --loop export-venv --dest $dir $targets
, and the venv would be recreated each time the inputs had changed
❤️ 1
💯 1
recent versions of PEX have a
entrypoint that supports creating a venv from a PEX: https://gist.github.com/stuhood/29082674e1558fbc111824a8e0ebbfb1
made a lot of progress on this today, but it’s not quite done: should be able to get it wrapped up in the next few days though.
👍 2
this landed, and should be in today’s
a few notable changes: 1) there is no need to use
in most cases (obviously in hindsight), because if the process is long-lived it will already sit and wait for things to happen, 2) the flag on
, etc) ended up being
rather than “interruptible”, which was ambiguous (since we will “interrupt” things when you Ctrl+C, regardless of any setting)
💯 1