take timedelta kwargs in after_deploy

[ryanhiebert]

Additional imports in migrations are cumbersome, but not necessarily unreasonable. The way that I can see to avoid them is to take the same keyword arguments in the after_deploy classmethod, and automatically create the timedelta if they are given. Depending how much we like it, we could even drop the delay= kwarg in favor of those keyword arguments, since we haven't released the new API yet.

The delay argument feels like the correct data type. I generally try to avoid passing along kwargs like that, to avoid challenges where the keys might overlap. But so far I'm not imagining any use for additional keyword argument in any of the Safe classmethods.

So I'm a little ambivalent on it, but I feel like it might be appropriate to take a little bit of risk in order to simplify the DX by just supporting the keyword arguments directly. What do you think?

[tim-schilling]

If the goal is to avoid imports, what about a separate method? Safe.after_deploy_in(days=) Then leave after_deploy as it is?

If that doesn't strike your fancy, then I can on board with specific kwargs or the variable kwargs being for timedelta.

[ryanhiebert]

If we were to write a migration generator, which version would be the canonical representation?

[tim-schilling]

Both, no?

[ryanhiebert]

I think my question here wasn't clear. If we had both delay and exposed the timedelta kwargs directly, which should be the preferred representation, that we'd write automatically in a file we generate. I think that's similar to #67 where we're deciding what's our preferred spelling of the default versions of our API.

Also, #68 is relevant to this, because the most likely implementation I see for that is to add a keyword argument to the classmethod. I think we are unlikely to want a keyword argument that would conflict with timedelta, but I hadn't seen use for any other keyword arguments previously.

If we do add this, I think I'd prefer specific or variable kwargs over the additional method. In no small part because I think anything we would want to add to this API would likely be in both methods, so it's two methods worth of signatures we'd have to keep in sync.