Allow app.run inside of functions #2883
Conversation
…ounts from within running functions iirc, the checks were mostly in place to prevent unnecessary logic from running in global scope of containers, but just adding pre-defined mounts to a list wouldn't account for many clock cycles, and this change still prevents auto-mounting from running within containers (soon to be deprecated anyways)
The intent of it was to prevent usage of app.run in global scope of modules that would then get loaded in containers causing an infinite recursion. This is not as likely to happen anymore now that we have the `modal run` cli instead of `if __name__ == __main__` as the main app launcher mechanic
One thing that I might be missing is why the error message mentions |
I think it was intended to nudge people towards using |
|
Does this need a rebase? |
|
We could in theory set some global variable during code imports to prevent this case more selectively. Not super important though. |
…allowing app.run within functions themselves
Good idea, I just applied that to the PR |
In the same vein as #2882
The intent of it was to prevent usage of app.run in global scope of modules that would then get loaded in containers causing an infinite recursion. This is not as likely to happen anymore now that we have the
modal runcli instead ofif __name__ == __main__as the main app launcher mechanicCheck these boxes or delete any item (or this section) if not relevant for this PR.
Note on protobuf: protobuf message changes in one place may have impact to
multiple entities (client, server, worker, database). See points above.
Changelog
with app.run(): .... Use with care, as putting such a run block in global scope of a module could easily lead to infinite app creation recursion