1. 1
  1.  

  2. 1

    I’ve had a hard time with the homebrew team in the past. I’ve also found maintaining a comprehensive Elasticsearch client to be something of a nightmare which is only bearable because people are nice and send PRs.

    Edit: in the interest of making this a more useful comment, here’s a brief commentary:

    I’m happy for Homebrew users to remain on Elasticsearch 1.x until this is resolved.

    Not out of the question. 2.0 doesn’t have features/changes that are all that critical for users from what I can tell. It’s not part of Bloodhound’s test suite yet either. Partly out of irritation that they changed the URL download scheme, so now we’ll have to special-case the CI build.

    We have a conflict_with DSL we use to indicate this but it just means some software can’t be installed at the same time. We resolve this by installing things to libexec, as we have done with Elasticsearch in the past.

    Seems reasonable.

    That’s why we don’t allow jars in lib. That’s exactly how Homebrew works and has always worked.

    This sounds weirder if you’re accustomed to C/C++ style vendoring.

    You’ll note I’m not submitting a PR or issue to your project asking you to change your code.

    That’s how open source works.

    Getting a bit petty.

    I’m happy for Homebrew users to remain on Elasticsearch 1.x until this is resolved.

    I don’t understand this as that doesn’t seem in the best interest of Homebrew’s users.

    ES dev overestimating importance of getting new users on latest ES version.

    We will very likely be establishing an official Elasticsearch tap going forward. Whatever the outcome, you can track the status of this on elastic/elasticsearch#14424.

    shrug

    It’s worth noting here that Homebrew is exclusively run by volunteers in their free time and that’s not the case for Elastic.

    #ShotsFired - but it’s true and this causes problems for third-party client maintainers like me too. They do basically nothing to try to make our jobs easier, never pitch in, little/no contact, etc. Only Haskellers have helped out.

    With respect, I’ve been a Homebrew maintainer for just under 7 years and I think I’ve got a pretty good grasp of what’s in our users best interests. To merge this as-is will cause additional issues. None of our audit rules are there for no reason, they have all been added to prevent previous issues from recurring.

    I’d take his word for it on this.

    I don’t doubt that for a second. I’ve been a Homebrew user for a long time, and it is the only package manager that I have installed on my systems; that should tell you the level of respect and appreciation that I have for the work of the Homebrew maintainers including yourself.

    /me obscene gesticulations

    when prior to your recent comment it was appearing that we weren’t going to get anywhere you were effectively banishing Homebrew users to a rapidly-aging version of Elasticsearch that will soon be out of support.

    Rapidly-aging is whose fault? ES upgrade treadmill has been obnoxious lately and the improvements have been pretty hand wobble. I don’t think prod ES users will see it this way. They’re nuts if they think production users have been upgrading clusters for every point release, especially given how easy it is to lose all your data with an ES cluster. Further, this is for Homebrew. Nobody’s deploying ES on retina Macbook Pros, so this is probably mostly about developer uptake. It’s not difficult to download an ES tarball and run bin/elasticsearch.

    What would happen if we installed the libraries to libexec/lib and make libexec the home (thanks @xu-cheng)?

    Sounds reasonable and like Homebrew peeps are trying to make it work, but I don’t know Homebrew details that well.

    1. 1

      What I see is: a negotiated solution, CI green, PR on track for being merged.

      LGTM!