OpenSearch Client Java & Python APIs

That looks like a great list. A few things to consider:

  1. Keep an eye on the project roadmap. The project uses semantic versioning, so no breaking changes are expected in 1.x but at 2.0 you’ll start to see some breaking changes (as an example, mastermain or whatever the new term ends up being).
  1. The OpenSeach plugins could probably have an native API in the client
  2. I’m not super familiar with this aspect of the python client, but having extensibility for additional plugins would be really helpful.

I’m try to do many of them in my client fork [GitHub - aparo/opensearch-client-generator: OpenDistro Client code generator to be used with Elasticsearch].
I removed xpack stuff.
I had a working typed AST in scala to be used to generate code i different languages.
I want:

  • target python 3.6 or above.
  • Asyncio by default (with tips to call old python blocking style code)

I hope to be able to work on it on night/spare time ;-(

1 Like

Hmm, maybe I can wait for a client build from you. I can check what features or transport layer are missing from the generated client.

@searchymcsearchface Most of the client code is generated from a set of spec files from the upstream build.

  1. The OpenSeach plugins could probably have an native API in the client
  2. I’m not super familiar with this aspect of the python client, but having extensibility for additional plugins would be really helpful.

As long as the spec is generated somewhere, a generator can generate client code from those spec. I am not sure how the spec is generated or written. This seems belong to OpenSearch repo.

  1. Keep an eye on the project roadmap. The project uses semantic versioning, so no breaking changes are expected in 1.x but at 2.0 you’ll start to see some breaking changes (as an example, mastermain or whatever the new term ends up being).

I think @aparo and I both try not to break compatibility to talk to OpenSearch cluster. But we want to ask users to change their code using the new client library. As of how much change users have to make, that can be discussed. All in all, elasticsearch-py 7.x should be able to talk with OpenSearch since day 1. It sounds like a good enough compromise.

Plus one to Asyncio!

Is there anyone looking into also migrating the Elasticsearch DSL Python library yet?

The Elasticsearch Python client just got a product check built-in, that will even prevent v7.14+ from being used with e.g. the 7.10 oss-distribution, hence forcing people to use 7.11 and thereby Elastic License v2…

Can you send a link to the PR that breaks it?

Here’s the related PRs and issues:

1 Like

The NodeJS library has the same “feature” [Backport 7.x] Verify connection to Elasticsearch by github-actions[bot] · Pull Request #1497 · elastic/elasticsearch-js · GitHub

Thanks for calling these out. :expressionless:

1 Like

Hi,

Has there been any work on a python GitHub - elastic/elasticsearch-py: Official Elasticsearch client library for Python yet?
I either need to pull the previous version before the ‘license check’ or move to a new lib.

Thanks,

Tony.

Yep. Work is happening but it’s going to a few weeks until the client libs are public (renaming and updating license headers requires both engineering and legal review). Yesterday the first non-AWS committer was invited to a client lib, which should help the velocity.

Until then use the client version right before the check was implemented (the highest 7.13.x usually) - see the documentation Compatibility - OpenSearch documentation .

2 Likes

Python clients (dsl and low level) have been released

repos

2 Likes