Add an `--ids-only` flag to easily extract ID's from a search.

[cholmes]

Looking into this, is all this work to get a comma-separated list of ids from the search? Whew, we (CLI, SDK) should make it easier 😆 Maybe add an --ids-only flag?

Originally posted by @jreiberkyle in #642 (comment)

[cholmes]

Note that the place this is most needed is in planet data search, so the results can be passed into orders API. See like https://planet-sdk-for-python-v2.readthedocs.io/en/latest/cli-tutorial/#bringing-it-all-together in the second one we could eliminate the obscure | jq -r .id | tr '\n' , | sed 's/.$//' which is just formatting id's into the format needed.

[sgillies]

@cholmes @kevinlacaille I've got a different take on this. Instead of modifying the output of planet data search to suit the input of planet orders request, what if we flip it around?

Postel's law (https://en.wikipedia.org/wiki/Robustness_principle) says that programs should be conservative in what they send, but be liberal in what they accept. I think that applies to our SDK and CLI. If planet orders request accepted not only a list of item ids, but also a list of search items, and extracted the ids from them, planet data search wouldn't need to change.

I think enhancing planet orders request might also be less error prone. A planet data search can search across multiple item types and if we only extract the ids from the search results, we can lose track of which item types they map to. Whereas planet orders request could group items by item type and keep this information together.

[jreiberkyle]

@sgillies this paradigm makes a lot of sense to me. It appears the primary use case here is creating an order from search results, so enhancing planet orders request could also work. On the other hand, this would add some complexity to planet orders request and not be a trivial change. @kevinlacaille what do you think?

[sgillies]

@jreiberkyle I've got another one for you 😄 https://wiki.c2.com/?ConservationOfComplexity. Getting a comma-separated list of ids from planet data search requires waiting on all results to come back and then it might mix PSScene and SkySat ids together, which offloads complexity onto the user. I think planet orders request, which already carries well so much complexity for us -- making orders is really complicated -- could take on even more complexity without becoming unusable.

[cholmes]

A planet data search can search across multiple item types and if we only extract the ids from the search results, we can lose track of which item types they map to. Whereas planet orders request could group items by item type and keep this information together.

To be clear this would require a pretty major change in functionality to planet orders request, as right now it can only handle one item type, and planet orders create similarly can only take input of one item type at a time. So if we're to enable piping in mixed PSScene and SkySat item types then we'd need an alternate flow. Like planet orders request outputting to requests? And planet orders create being able to take multiple of orders and create one order per?

Getting a comma-separated list of ids from planet data search requires waiting on all results to come back

Well realistically right now the maximum wait would only be 500 items, since that's the max a single order could handle. #746 will hopefully address that, and will also lead us down the path of creating more than one order on a single command.

Overall I do like the idea, I just don't think the argument about mixing item-types is that compelling, at least until we built the mechanism for our orders commands to handle multiple item types. Which is a direction I'm interested in, but is a non-trivial amount of work, and first I'd do the 'large orders' as that was a super clear user request, while mixing item-types from search results piped into orders is a bit theoretical, and is beyond the capabilities of our core API's.

I'm right now leaning towards 'both' - get the --ids-only in, but then take on making orders better in general and accept more. @sgillies I think if you'd brought this up earlier, before work had been done, I'd be convinced to just go that route, but I don't know that we should let great be the enemy of good and right now prefer to get this in and continue to iterate. I also think --ids-only can be useful just to more easily see the ids, instead of getting a wall of json output. I can be convinced otherwise if you feel really strongly about it Sean, and we have a full plan & design to actually handle large orders and be able to pipe in mixed item-type results.