1

:wave:Hi folks,
I work for HashiCorp and I firstly want to thank the community for the amazing work on maintaining formulas for our software, namely terraform, vault, packer, consul, nomad, vagrant and sentinel.

Thank you! :bowing_man:‍♂

I’m in the process of researching our options with regards to automating the process of publishing of new versions of our software to different platforms, including MacOS/Homebrew. I am aware that a 3rd party tap is an option for us and I think it’s a viable one, but I’d like to ask some question before we embark on that journey.

Are there any best practices for software vendors (like HashiCorp) whose software is already being distributed through the main tap/repository? I do not want to cause too much disruption to users who are already consuming our software through the main tap (Homebrew/homebrew-core), but if we do begin to publish updates through our own tap we’d likely want to treat it as the preferred way.

  1. Would you (Homebrew maintainers) want/expect vendor’s taps to be the exclusive place from where to install/update their software from, or would you prefer the tap to be additional to the existing formulas?
  2. If you prefer the formulas to remain in the main tap - is there any process for automating updates that we could integrate into our release pipeline, or is the main tap designed for human-based updates? i.e. would automation be fragile as humans edit these files?
  3. If you prefer for the formulas to move to our tap - would you be open to migrating Homebrew users of these formulas to our tap via tap migrations? Based on this PR it appears that 3rd party tap migrations aren’t welcomed anymore - is there any particular reason behind it? Would this restriction also apply to to a tap that is maintained by the software vendor?

Another reason I’m also asking about this is because I wonder how would these decisions affect formulas which either conflict with or depend on ours, e.g. terragrunt or tfenv. Do the depends_on and conflicts_with stanzas work with external taps?

Generally custom tap would be the preferred option from my own perspective for the following reasons:

  • we’d have better control on how the software is compiled (e.g. what Go version and what compilation flags are used)
  • we can distribute updates in a timely fashion, which is important especially for security patches
  • we can distribute code-signed binaries
  • we can distribute the exact same (byte-to-byte) binaries to Homebrew users as we distribute through other channels, which can help with archive verification based on the checksums and signature we publish for every release. I appreciate Homebrew has checksum verification of its own, but GPG can be important for some users.

With all that said I don’t want the decision to come across as disrespectful towards Homebrew maintainers or users - hence I’m raising the question here before taking actions.

1 Like
2

The prefered method for homebrew maintainers is definitely to keep the software in the main tap and since it is open source, we will probably keep distributing it even if you decide to make an external tap. As for the automatic updates, there’s a couple of github actions that automatically create updates and as a maintainer those are actually preferable to people editing things manually, this since the script rarely makes mistakes.

If you really want to have those benefits of the custom tap I’d suggest to just distribute the software twice, once in the main tap and once in your own. The main tap will be build with the latest tools and people can rebuild it locally and the custom tap will have all the benefits you listed.

3

As @SMillerDev said. We’re happy in the case of good open source producers/consumers like Hashicorp and friendly faces like yours @radeksimko to consider more changes that upstream would prefer.

To answer your questions specifically:

We’d prefer to keep as many users using homebrew/core for these formulae as possible and keep your tap for special needs (e.g. those who “byte-to-byte” binaries)

As @smillerdev said Homebrew bump formula · Actions · GitHub Marketplace · GitHub and similar are your best bet.

We don’t trust (any) third-party vendors to run taps to our standards and principles so we aren’t willing to redirect our users there automatically.

Yes. We don’t accept references to taps in homebrew-core but you can do the opposite.

A tip: you may also find your experience running a tap to be a bit nicer if you don’t use the same formula names e.g. terragrunt-official or something rather than terragrunt if you want to ensure the dependency tree only uses the formulae from your tap.

Thanks! Appreciate the heads up. From our perspective:

  • homebrew/core is easiest for users for discoverability and tooling (e.g. https://formulae.brew.sh)
  • homebrew/core is easiest for Homebrew maintainers for being able to use new DSLs, make mass fixes, update formula for new macOS versions
  • we’re prepared to address issues that are causing upstream issues to be filed

My personal take:

  • There’s an increasing desire in commercial open source about “maintaining control” e.g. defining exactly what binaries are shipping to users. Not supporting users (and, even mores, software distributions) to build-from-source is antithetical to the values of open source. If you think Homebrew is annoying on this: try and see how Debian responds to requests to ship your binaries.
1 Like
4

Thank you for all the answers and for explaining the reasons too. I understand that keeping most of the ecosystem close to you comes with the benefits you mentioned

We went through a very similar journey with Terraform and its providers (maintained by the community) in the past few years and I can see how it changes the conversation about changes to anything that may impact the ecosystem.

TL;DR I understand your decisions here better than you may think :smile:

I understand that point of view, and thankfully we didn’t have too many issues from users related to compilation of our software and I certainly do not want us to prevent anyone from doing that or say that it’s unsupported. That said we may be in this position mostly thanks to the Go cross-platform toolchain and our ability to leverage it. i.e. the cost of supporting build-from-source is relatively low.

I don’t think Homebrew is annoying on this.

I don’t have experience with Debian specifically, but it seems to be common for Linux admins in bigger companies to seek and use vendor’s own upstream repositories, even when them same software is available from community-maintained sources and vendor’s education materials often do include an instruction do add their custom Linux repository before installing the software. This may have different motivations and the practice may differ depending on how critical the software is for the company or who the vendor is, but the point is that external repositories seem to be a common practice in that segment of Linux user base.

It seems to me that the concept of taps is comparably less known to Homebrew users and vendors, so maybe that’s something to address? Perhaps there could be a dedicated docs page which summarizes your points above, kind of an FAQ or best practices for vendors?

Unfortunately “support” is IMO an overloaded term which different people understand differently. From practical perspective we need to set the expectations on what is “best-effort/community support” and what do we support through channels for paying customers, because each has different (financial, legal and many other) implications. Different vendors may have different business models and their critics, but I think universally a lot of frustration (rightly) comes when vendors of OSS decide to only support paying users, and/or don’t set clear enough expectations around this. We are not flawless, but I think that these topics are on the top of our minds within HashiCorp.

I will share this thread with my colleagues for context, but I’m more inclined to maintaining our tap in addition to the formulas in core as you suggested. This does NOT mean we want to stop supporting build-from-source or the core tap, but I want us to be clear about explicit and implicit (best effort) support. As a result this would likely have implications for our education material and potentially the product websites which would prefer installation from the tap, as opposed to the core formulas.

Sorry for the long post, but I hope the context and explanation is useful.

4 Likes
5

Sounds good, good explanation. In short: I understand that in your case providing taps for commercial customers with paid support contracts will make more sense to both them and you then using our binaries and I’m glad to hear you agree that this will be a nice complement to homebrew-core formulae rather than (as some other vendors have done) any sort of demand to remove our formulae!

Thanks again @radeksimko!

This is a good idea as it comes up again and again :+1:

6

Gotta thank you for requesting input from homebrew instead of making a PR demanding we drop support.

1 Like
7

Does this apply to dependencies of the formulas in the tap, or all formula names there? Could you expand on the reasoning behind this tip?

I assume that even if the formula name differs and binary name remains the same the two formulas would still effectively fight for their symlink within /usr/local/bin, right? I assume that Homebrew would notice an existing symlink and let the user overwrite it via brew link in one direction or the other though?

Relatedly is conflicts_with stanza evaluated in both directions, once an affected formula is installed?

e.g. if someone installs hypothetical hashicorp/tap/terraform, which has conflicts_with "terraform" and then (either by mistake or consciously) triggers installation of terraform (from the core tap) - will they see a an explicit conflict or will the formula install and Homebrew will just inform them about an existing symlink and prompt finishing installation via brew link?

btw. I know I could probably just test the above to get an answer, but the point of me asking here is also understanding whether these are conscious and still valid decisions as sometimes things work in a certain way by accident or context/situation changes and past decisions are no longer valid.

8

This applies just to the formulae in the tap. The reasoning is that you can then ensure that you have a separate prefix (e.g. /usr/local/Cellar/terragrunt-official/$VERSION which will never have the parent directory shared with the formula in Homebrew/core. We do our best to ensure that those play nice but e.g. if people are used to doing brew tap HashiCorp/homebrew and then brew install terragrunt they will get the Homebrew/core rather than Hashicorp version. If you tell them to brew install terragrunt-official then it’ll error out unless the tap is installed.

Correct. You can use conflicts_with or keg_only to deal with this.

We’ll present an error and options for the user to address it (overwriting with a flag or removing manually).

No, it is only one directional.

No, I’m glad to have the questions, honestly. This is classic “should be written down somewhere” stuff and I’m hoping you extract from me all the stuff I should have written down :joy:

2 Likes
9

Just to jump in with a thought (and no actual implementation - just an idea…so, feel free to ignore/roast me): would there be any possibility of adding a stanza for “official_tap” or something - so that just like a user could “pin” a formula to a version, they could also specify (by checking out the tap) that they want to use the official formulas instead. Some kind of naming convention could be helpful as well

Perhaps something like this (using the example of terraform): a stanza is added to the core formula for “official_tap: HashiCorp/terra” or something. If a user tries to “brew install terraform” (or install a formula that delends_on: terraform), the core formula will look for if the user has tapped HashiCorp/terra, and if they have, instead of installing core/terraform, it will install HashiCorp/terra/terraform-official. Basically, a way to have a “shortcut” to the official version, if desired by the end user.

The use case for that would be that I - as a paying customer of HashiCorp (but not affiliated with HashiCorp) would prefer to use their official distribution. However, when I install the hypothetical third party “awesome-project” (which neither HashiCorp nor I Control or maintain - but which depends on terraform), I want homebrew to magically “just work” and install the binaries that I (as the user of home brew and paying customer of HashiCorp) expect to be installed. Link error and conflicts are good from a technical perspective to prevent the user from doing dumb things - but sometimes they can complicate things when you want to do this sort of “split” installation.

Clearly, there would need to be some significant validation of the “official” repos before blindly installing from them, and there would need to be some kind of indication of what exactly is getting installed.

I also don’t have the slightest clue of how it would best be implemented or work…I’m kind of just spitballing here. It just seems to me as a user of homebrew and a customer of HashiCorp that there is an opportunity for improving the experience for my particular use case (which I don’t see as completely out-of-the-ordinary), while still providing the open source implementation and ease of use/discoverability that homebrew is so amazing at.

10

Anyone with this degree of self-awareness is extremely unlikely to be roasted or ignored :smile:

We have kinda had that in the past with the brew tap-pin commands.

Unfortunately, they were a bit of a hack that never worked consistently. Unfortunately Homebrew is built with too many assumptions that a user/repo/formula and foo/bar/formula are (at least in some ways) “the same” i.e. they are both installed to Cellar/formula so inherently clash.

I like the intent but the problem is: the end user may trust the “official” version more than ours but we don’t :hear_no_evil:. We trust our security model more than those for taps and we don’t want that to be a shortcut for a tap being pwned and our users being bypassed onto that.

The best I can suggest for now (and I’m open to more suggestions) is somehow making it easier for “official” vendor repos to be able to run their taps and tell users with support contracts about them. I’m not sure how/what this would be beyond sending these installation instructions themselves when you get a contract.

I think the problem is: it’s not just a one-off validation we’d require but effectively a continuous validation and trust process which e.g. Hashicorp is unlikely to let random open source maintainers validate (and arguably: they shouldn’t).

I agree there’s room for improvement here. Maybe the docs I plan on writing will shed light on them?

Thanks for the kind words and well-written comment in general, much appreciated :heart:

2 Likes
11

Thank you for your consideration - and everything you say does make sense. I appreciate all the time and efforts you (and everyone else) puts in to homebrew.

I do think this line of thinking can become a slippery slope - and, while I agree with and greatly admire the security efforts that are an integral part of the homebrew community, there is potential for others to not fully appreciate those efforts. Security is not just a binary “yes/no” decision, and there are many different approaches…most of which are “different from” and not necessarily “better than” each other.

Accepting anyone’s approach to security just because “we trust ourselves more than others” is asking a lot. Granted, in some cases (the core homebrew case included), it is completely backed up by facts and policies.

However, I can see end users asking why they should trust the security of the core homebrew repo more than the security of the official vendor. And I can see end users seeing this policy as not trusting their own explicit decisions and security choices in favor of the decisions made in the core homebrew repo.

Not that I see it as a bad thing (we outsource security decisions on a daily basis) - and I think it just comes down to documenting security practices and helping users understand why decisions are made the way they are. I don’t disagree with this approach, and it makes complete sense from a technical and security perspective.

Again, I am not trying to change policies or approaches (this is my long-winded way of agreeing with you). Your explanation here was very helpful, and I think some of these security-related arguments should be included in the documentation you reference.

12

Yup, agreed. I think for us the added dimension is that we’re not just dealing with “explicit decisions and security choices” but also thinking “how will this be (ab)used and how will users respond”. There’s also the idealogical side that we’re not just a software distribution method but an open source software distribution method run by volunteers and part of a free-software oriented non-profit so our values come into this a bit, too.

13

As promised: opened a PR in docs/How-to-Create-and-Maintain-a-Tap: official vendor taps. by MikeMcQuaid · Pull Request #7536 · Homebrew/brew · GitHub

1 Like
14

Thanks for the PR.

Just wanted to add that I appreciate the suggestion to use entirely different name for formulas, but the downside is that it makes the FQN pretty verbose, e.g.

brew install hashicorp/tap/terraform-official

(which may be why most of the external taps don’t follow this suggestion?)

Also using the same name comes with an added benefit (side effect) of still preventing the installation of core formula when the one in tap is installed. The UX isn’t ideal, but I think the outcome is probably safer than letting two fomulae be installed side by side.

I understand why you wouldn’t want to go as far as listing conflicting formulae in external taps, but would you still be open to improving the UX e.g. by evaluating the (installed) formulae conflicts_with - so that installation raises e.g. an advisory message in scenario outlined below?

brew install hashicorp/tap/terraform-ls
brew install terraform-ls

and relatedly would you be still open to improving the UX when formulae names match?

FWIW I’m not asking anyone to do the work, but rather understand where you stand and whether such contribution to Homebrew/brew would be welcomed or not. :smiley:

15

Yup, I’d definitely encourage PRs for both of these :+1:

1 Like