Official Python client vs PyES


(Zaar Hai) #1

Good day,

I've noticed that official Python clienthttp://elasticsearch-py.readthedocs.org/en/latest/for Elastic Search was announced some time ago.
Till now I was using PyES https://github.com/aparo/pyes and was pretty
happy with it.

Quick looking at the new clients, the API looks very similar to PyES,
however the code does not.

So I have a couple of questions:

  1. ES developers - why did you decide to start a new project and not to
    "adopt" PyES.
  2. Community - which client do you prefer and why?

Thanks,
Zaar

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Honza Král) #2

Hello Zaar,

Our decision to create our own clients was mostly about consistency for our
users. To do that we created a set of low-level clients that map very
closely to the REST api. We made sure (and are continuously doing so) that
these clients implement all the API endpoints as well as all parameters and
to the right thing.

We tried our best to avoid any design decisions in those clients to make
sure everybody could use them, even if it means creating their own
abstraction on top of it. The overhead of the clients are so small and
their design flexible enough (we hope) that all the other clients can live
on top of these.

I hope that answers your first question. For more information I'll be doing
a webinar about this - why we chose to do the clients, what drove the
design decisions we took and what is the future of the python client(s). It
should take place next week sometime.

Thanks!

Honza Král
Python developer for Elasticsearch

On Thu, Oct 24, 2013 at 11:00 AM, Zaar Hai haizaar@gmail.com wrote:

Good day,

I've noticed that official Python clienthttp://elasticsearch-py.readthedocs.org/en/latest/for Elastic Search was announced some time ago.
Till now I was using PyES https://github.com/aparo/pyes and was pretty
happy with it.

Quick looking at the new clients, the API looks very similar to PyES,
however the code does not.

So I have a couple of questions:

  1. ES developers - why did you decide to start a new project and not to
    "adopt" PyES.
  2. Community - which client do you prefer and why?

Thanks,
Zaar

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Zaar Hai) #3

Hi Honza,

Thanks for the explanation. It makes sense.
Where can I find more info about this webinar?

Zaar

On Thursday, October 24, 2013 2:40:16 PM UTC+3, Honza Král wrote:

Hello Zaar,

Our decision to create our own clients was mostly about consistency for
our users. To do that we created a set of low-level clients that map very
closely to the REST api. We made sure (and are continuously doing so) that
these clients implement all the API endpoints as well as all parameters and
to the right thing.

We tried our best to avoid any design decisions in those clients to make
sure everybody could use them, even if it means creating their own
abstraction on top of it. The overhead of the clients are so small and
their design flexible enough (we hope) that all the other clients can live
on top of these.

I hope that answers your first question. For more information I'll be
doing a webinar about this - why we chose to do the clients, what drove the
design decisions we took and what is the future of the python client(s). It
should take place next week sometime.

Thanks!

Honza Král
Python developer for Elasticsearch

On Thu, Oct 24, 2013 at 11:00 AM, Zaar Hai <hai...@gmail.com <javascript:>

wrote:

Good day,

I've noticed that official Python clienthttp://elasticsearch-py.readthedocs.org/en/latest/for Elastic Search was announced some time ago.
Till now I was using PyES https://github.com/aparo/pyes and was pretty
happy with it.

Quick looking at the new clients, the API looks very similar to PyES,
however the code does not.

So I have a couple of questions:

  1. ES developers - why did you decide to start a new project and not to
    "adopt" PyES.
  2. Community - which client do you prefer and why?

Thanks,
Zaar

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Honza Král) #4

The info is now out:
http://www.elasticsearch.org/webinars/the-why-and-what-about-python/

On Thu, Oct 24, 2013 at 1:58 PM, Zaar Hai haizaar@gmail.com wrote:

Hi Honza,

Thanks for the explanation. It makes sense.
Where can I find more info about this webinar?

Zaar

On Thursday, October 24, 2013 2:40:16 PM UTC+3, Honza Král wrote:

Hello Zaar,

Our decision to create our own clients was mostly about consistency for
our users. To do that we created a set of low-level clients that map very
closely to the REST api. We made sure (and are continuously doing so) that
these clients implement all the API endpoints as well as all parameters and
to the right thing.

We tried our best to avoid any design decisions in those clients to make
sure everybody could use them, even if it means creating their own
abstraction on top of it. The overhead of the clients are so small and
their design flexible enough (we hope) that all the other clients can live
on top of these.

I hope that answers your first question. For more information I'll be
doing a webinar about this - why we chose to do the clients, what drove the
design decisions we took and what is the future of the python client(s). It
should take place next week sometime.

Thanks!

Honza Král
Python developer for Elasticsearch

On Thu, Oct 24, 2013 at 11:00 AM, Zaar Hai hai...@gmail.com wrote:

Good day,

I've noticed that official Python clienthttp://elasticsearch-py.readthedocs.org/en/latest/for Elastic Search was announced some time ago.
Till now I was using PyES https://github.com/aparo/pyes and was
pretty happy with it.

Quick looking at the new clients, the API looks very similar to PyES,
however the code does not.

So I have a couple of questions:

  1. ES developers - why did you decide to start a new project and not to
    "adopt" PyES.
  2. Community - which client do you prefer and why?

Thanks,
Zaar

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@**googlegroups.com.

For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(system) #5