-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client-side app-less sandboxes #1957
Conversation
b16f498
to
edb9b13
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Should we add a deprecation message for the old code path?
_experimental_scheduler_placement=_experimental_scheduler_placement, | ||
) | ||
app_id: Optional[str] = app.app_id if app else None | ||
resolver = Resolver(client, environment_name=environment_name, app_id=app_id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we able to resolve all deps without an app ID?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah should be fine – it's just images that need it and i fixed that in the backend
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually it's possible secrets need it too, let me check
] = {}, # Mount points for Modal Volumes and CloudBucketMounts | ||
pty_info: Optional[api_pb2.PTYInfo] = None, | ||
_allow_background_volume_commits: Optional[bool] = None, | ||
_experimental_scheduler_placement: Optional[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah looks like we still need to add the non-experimental scheduler param, now that it's out. Outside the scope of this PR.
@@ -323,6 +330,63 @@ async def _load(self: _Sandbox, resolver: Resolver, _existing_object_id: Optiona | |||
|
|||
return _Sandbox._from_loader(_load, "Sandbox()", deps=_deps) | |||
|
|||
@staticmethod | |||
async def create( | |||
*entrypoint_args: str, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make the following args keyword-only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah good point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually believe they are keyword-only because of the * automatically (i just learned something new about python!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh cool, makes sense! (any args would be spread into entrypoint_args
so it has to be this way)
Ok slightly bad news: in order for this to work, we need to support app-less secrets and mounts as well. The good news is that this is something I've been hoping to add support for anyway for a while. But it will take a bit of time to figure out how to do it, unfortunately. |
Was planning to do that in a subsequent PR (I want to update some integration tests and docs first) |
This works now, but lack of output is a bit confusing with custom images.
|
Ah yeah, I think we used to be able to see output in the app logs, but decoupling makes that difficult 🤔 |
I think we can fix this in a different way. I've had it on my backlog for a long time to break out the output management into a singleton (separate from the resolver) that you can activate using a context manager (with the idea that all CLI commands enable this automatically). Something like with modal.enable_logs():
... I don't love singletons but in this case I think it's fine since stdout is already a singleton |
ok this FINALLY works
|
Implements the basics of this. Demo:
TODO for this PR:
Will do in subsequent PRs: