-
Notifications
You must be signed in to change notification settings - Fork 204
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
Improve the ergonomics of awaiting predictions #204
Comments
@zeke I'm pretty sure we don't document that anywhere, but const output = await replicate.run(model, { input }, ({ id, status, logs }) => {
console.log({ id, status, last_log_line: logs.split("\n").pop() });
}); How does that feel? |
Good to know! That's definitely useful, but maybe not entirely intuitive. Imagine coming upon this code without having read the docs. Would you understand that that callback was a progress event? Either way, we should document that! |
Not that code golf version, no. But there are more self-documenting ways to write it: callback = (prediction) => {
const last_log_line = prediction.logs.split("\n").pop()
console.log({id: prediction.id, log: last_log_line})
}
const output = await replicate.run(model, { input }, callback) But more to your original point: I don't hate |
Yep that snippet is definitely more intuitive. Could probably take it a step further by naming onProgress = (prediction) => {
const last_log_line = prediction.logs.split("\n").pop()
console.log({id: prediction.id, log: last_log_line})
}
const output = await replicate.run(model, { input }, onProgress) ☝🏼 I know I'm being pedantic here, but the goal is to get to a code snippet for the docs that feels clear and unambiguous.
Nice! I thought I'd seen that somewhere. I forgot it was the Swift client. |
A comment from @deepfates on replicate/create-replicate#39 (comment)
☝🏼 Coming at this from a different angle: what if Maybe not a great idea, as I know that's unsavory from a good-programmer typed-languages perspective to have a function that returns differently shaped objects based on its inputs. But it could also be a nice way for people to migrate from the existing |
@zeke I think that gets to the underlying question: Do we want to make predictions more or less prominent in our system? I'd argue that a prediction a means to an end. It's ephemeral. Like a train ticket, once you get to where you're going, you don't need it anymore (and ideally, you wouldn't need one at all). Except in the cases where you're still in transit or you didn't reach your intended destination, why hold onto it? Why should someone care about a prediction object in the first place?
|
Here is a better version of starting a prediction with
|
@onurkose FYI - |
The
replicate.run
method provides a nice way of running a prediction and getting its output with a single line of code:That's nice if I only want the prediction output. But what if I want the whole prediction object? For example, maybe I want to know the prediction id, or see how long the prediction took to run. In this case, the best option is this:
That works, but it's not ideal for a few reasons:
replicate.prediction.create
is itself an async function makes me think that maybe I'm awaiting its completion too, when in fact I'm actually just awaiting the empty shell of a prediction.wait
call is on thereplicate
object, rather than on theprediction
instance itself. This is confusing.const
because I have to re-assign it when I callwait
. It feels weird to create a thing and then overwrite it entirely, especially in the age of JavaScript constants.How can we make this better? My off-the-cuff idea is a
wait
option on thereplicate.predictions.create
method:What do folks think of that? Open to ideas here.
cc @replicate/product @replicate/hackers
The text was updated successfully, but these errors were encountered: