You should add a description about the output format of that command.

Also maybe JSON output could be used instead of CSV one ?

I think you should move the client instantiation in the web group directly in that diff

You should add a page_token parameter to return a specific page of the found origins. Currently, only the first page is returned.
I also think the page_token value to get the next page of search results should be part of the command response.
FYI, that value must be considered as opaque, currently it is a number but once we will switch to elasticsearch as search backend the format will change.

See https://archive.softwareheritage.org/api/1/origin/search/python/?limit=2 as an example.

I also just noticed it is not documented, will fix that today.

This is not really a pattern. Rather, it's a list of keywords. They should be described as such to the user, and I think you should make the argument n-ary, as something that can be passed multiple times, one per keyword.

I don't think we want an explicit limit in the CLI.
I'd rather make the client retrieve everything, and let the user filter to a given limit downstream of the tool, e.g., with head, or with jq if we add JSON output.

May the UNIX philosophy be with you :-)

As long as it's lazy, the user can also always interrupt with Ctrl-C, and we have server-side rate limit to counter abuse anyway.

this is tricky to name in an intuitive manner, the best I came up with is

@click.option("--include-unvisited/--exclude-unvisited", default=False, show_default=True, help="...")

(also, it needs a help string)

add a help string, which also tells what's the default

also, my favorite form would be more explicit than this, e.g.:

@click.option("--url-encode/--no-url-encode", default=False, show_default=True, help="....")

(also, it needs a help string)

I'd like to have a textual/tabular (= CSV, with tabs as separator) output as default, because it's easier to read and manipulate with standard UNIX tools, such as cut.

I'm not against an optional output in other formats, including JSON. I'd see that as an additional feature though, not necessarily a blocker for a first implementation with another output format. YMMV.

+1, we really want pagination support for this one

imports should be at the top of the file

same here

you should add error handling here and prints exception message to give some feedback to the user.

This code is not covered, could you add tests for the CLI command ?

why is it needed ?

in which context the BrokenPipeError error is raised ?

You could make that block more compact the following way, also renaming json variable to origins makes the code easier to read:

nb_returned = 0
q = f"origin/search/{query}/"
while q and nb_returned < limit:
    r = self._call(q, params=params, **req_args)
    origins = r.json()
    if limit and nb_returned + len(origins) > limit:
        origins = origins[: limit - nb_returned]

    nb_returned += len(origins)
    yield from origins

    q = None
    if "next" in r.links and "url" in r.links["next"]:
        params = []
        q = r.links["next"]["url"]

This code is not covered, could you add a test for pagination ?