feat: support scheduling content - #485
Conversation
☂️ Python Coverage
Overall Coverage
New Files
Modified Files
|
lucasrod16
left a comment
lucasrod16
left a comment
There was a problem hiding this comment.
Taking a first pass at this and will followup with another pass. The overall API surface looks good to me so far
lucasrod16
left a comment
lucasrod16
left a comment
There was a problem hiding this comment.
This appears to be the first API resource in this SDK to use a set() method as opposed to create()/update(), but I think it provides a better UX since users don't have to know about or handle the create vs update decision and details themselves.
I think we should handle the app_mode == "unknown" case in content.schedule before merge, otherwise this LGTM.
tdstein
left a comment
tdstein
left a comment
There was a problem hiding this comment.
Looks good overall!
Although, the amount of logic required to make the Schedules API idiomatic in Python is unfortunate...
| ) | ||
| return variants[0] | ||
|
|
||
| @cached_property |
There was a problem hiding this comment.
Oh interesting. I've never used cached_property. Did you include this to avoid recomputing the default variant? Is there any risk that the default variant changes?
There was a problem hiding this comment.
Yes, it's there to avoid re-resolving the default variant. Without caching, create() followed by find_one() would look it up twice. I don't think the default variant changes so I think this should be safe.
Co-authored-by: Taylor Steinberg <taylor.steinberg@posit.co>
|
Thanks for the feedback everyone. I opted to rename from |
4 participants
This adds a way to manage schedules for content on Connect. Closes #484.
The default variant's schedule can be managed with
content.schedule, which supports looking up the schedule (find_one()), creating/updating a schedule (set()), and removing a schedule (delete()).variant.schedulesdoes the same for a specific variant.set()creates or updates as needed and has per-type overloads, so pyright catches invalid parameter combinations.Because this is backed by unversioned endpoints,
set()anddelete()emitFutureWarningsimilar to how we do forsend_mail:posit-sdk-py/src/posit/connect/variants.py
Lines 34 to 38 in 286d604
I'm a little on the fence about these warnings and am open to removing them. I do think it's good to convey that this functionality relies on unversioned endpoints that Connect may change or remove.