search

bitemyapp / bloodhound

Haskell Elasticsearch client and query DSL
bitemyapp.com
BSD 3-Clause "New" or "Revised" License
424 stars 118 forks source link

In nix stable and unstable, bloodhound is tagged as "broken" #283

Open metaml opened 3 years ago

metaml commented 3 years ago

Is there a plan to release bloodhound to hackage in the near future? If so, when?

The current version 0.16.0.0 in hackage is from 2018 and is failing to build due to PVP bounds and the issue with nix tagging it as "broken" would be nice to have fixed.

MichaelXavier commented 3 years ago

I would say that it would be a good idea to try to recruit some maintainers who are active users. I don't think either Chris nor I use the package anymore. I've not had time to be a good maintainer so if someone is getting use out of it, I'd like to allow them to keep it going. Is that something you'd be interested in? I can also put a notice in the README.

bitemyapp commented 2 years ago

I've invited 3 people to be collaborators on the repository who've contributed PRs and that seem trustworthy, let me know if there's anything else you'd like me to do to facilitate development and maintenance.

I can weigh in on design/API questions if people would like but I don't have time for the heavy-lifting, on track to have 3 kids under the age of 3 this year.

andrewthad commented 2 years ago

I accepted the invite, but I hate to say that I'm no longer an active user either. I do still use elasticsearch at work, but elasticsearch's API is just too much of a mess to target with a library. It introduces breaking changes a lot, and the main way to query Elasticsearch is just to go through kibana. At work, we use https://github.com/layer-3-communications/elasticsearch-interchange (our own library), which is a much less ambitious project than bloodhound. It supports bulk requests, bulk responses, and search responses (all at a high level). It could be a smarting point for anyone else going down this dreary road.

bitemyapp commented 2 years ago

The intense API churn and lack of machine ingestible schemas for the API is a huge problem. It makes maintaining a library that has a high degree of fidelity with the API's underlying schema and meaningful, safe representations in the types very laborious. Apart from it being unpaid labor, Elastic has never even given me the time of day when I tried to reach out to them about schemas or specifications that people could use to generate client APIs. Part of what baffles me about this is that generating clients from API specifications is clearly where the industry is headed more generally.

There's no incentive for me to tilt at these windmills unless I need the library to do something for me and I haven't in a long time. If Elastic wants people to contribute to their ecosystem for free they need to at least show some interest and talk to the parts of the community that are building things for their platform. They might not care about Haskell but what I wanted to discuss with them is something that would've benefited everyone including Elastic themselves as far as client dev & maintenance goes.