planet-client-python
planet-client-python copied to clipboard
planetlabs
Add helper method to create tools.json for orders and subscriptions
We can help users a lot by letting them use the command-line to specify what 'tools' options they want.
I think it makes sense to create a top level 'tools', with target outputs for subscriptions and orders. They have slightly different syntaxes, and the list of tools isn't exactly the same, so the output for each will be different. But from a user perspective there is a lot of overlap, so we should let users specify common operations in the same way.
First step is probably to agree on the 'spec', probably as a pull request to one of the design docs, and after we agree on that we can code it up.
The toolchain requirements and formats are different for subscriptions and for orders. It seems easier to just treat them separately until they come into alignment. I'd suggest something like planet subscriptions request-tools [OPTIONS] and planet orders request-tools [OPTIONS].
I'd be ok with starting them separately and later aligning. If we go that route I think the one thing that would be nice is a 'conversion' utility - like instead of 'options' you could point at a file of the other tools format and have it convert. Like `planet orders request-tools --file "/file/a-subscription-tools.json" ' So when users create a file in one format they can transform it to the other. Going from orders to subscriptions would have to raise errors if it tried to do an operation that isn't supported by subscriptions.
Yeah that would be really helpful and shouldn't be too complex to implement
@jreiberkyle - are you going to split this out into two tickets - one for orders and one for subscriptions?
I'm ambivalent about separating them or leaving them together. I've found that sometimes making tickets that are too small ends up with a lot of overhead and just breaking the tickets up at sprint planning time can be more beneficial. but I'm ok with them being split up if you'd like to do that now
I don't need to if you're ambivalent. If you'll tackle them at the same time then it probably makes less sense.
+1 for maintaining separate tools lists in the SDK until the APIs themselves are better aligned.
