Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove all options from Homebrew/homebrew-core formulae #31510

Closed
MikeMcQuaid opened this issue Aug 27, 2018 · 85 comments
Closed

Remove all options from Homebrew/homebrew-core formulae #31510

MikeMcQuaid opened this issue Aug 27, 2018 · 85 comments

Comments

@MikeMcQuaid
Copy link
Member

@MikeMcQuaid MikeMcQuaid commented Aug 27, 2018

Options in formulae don't produce a good user experience because they have to be built from source, we don't test them in CI and each combination of options provides a new chance for new failures to occur. We should seek to (eventually!) remove all options from formulae in Homebrew/homebrew-core in favour of enabling as much non-exclusive functionality as possible in a given formula for widely used options or encouraging the community to maintain their own custom options in a tap (e.g. https://github.com/denji/homebrew-nginx/blob/master/Formula/nginx-full.rb). As an absolute last resort if we need to depend on the same formula multiple times with different options (e.g.
#13133) we can consider vendoring formulae using resource blocks or even duplicating formulae.

This should be done in multiple phases:

  1. formulae that have build error issues created with particular options should have the options removed immediately (rather than a fix being merged)
  2. less popular formulae should have all their options removed
  3. popular formulae (e.g. https://formulae.brew.sh/analytics/install-on-request/90d/) should be prioritised for having their defaults adjusted (depending on analytics usage) to get the best balance of functionality without options.

I'm open to thoughts on the above and different approaches to solve the problem as well as additional tooling required in Homebrew/brew to accomplish this.

@jhrmnn
Copy link
Contributor

@jhrmnn jhrmnn commented Aug 27, 2018

What about a more general approach akin to Debian's alternatives system? That could handle the issue with options as well as other things.

One thing that I've always missed in Homebrew was being able to pick an implementation of MPI: Open MPI vs Mpich. Currently when one installs Mpich, packages depending on MPI (and so on Open MPI in Homebrew's logic), such as Scalapack, have to be built manually, else Homebrew complains about missing dependencies.

@chdiza
Copy link
Contributor

@chdiza chdiza commented Aug 27, 2018

Options in formulae don't produce a good user experience because they have to be built from source, we don't test them in CI and each combination of options provides a new chance for new failures to occur.

Those things do happen with options, but I don't think it follows that eliminating options provides a better user experience. A formula that lacks needed options means the user makes their own tap, in which case...it will be built from source, not tested by CI, and provides new chances for failure. I.e., those three things that an option-using user currently faces will still be faced just about as often once options are eliminated.

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Aug 27, 2018

What about a more general approach akin to Debian's alternatives system? That could handle the issue with options as well as other things.

We can't really do this given our limited CI and options aren't a good approach for this. "Picking an implementation" isn't really something Debian supports for compile-time things; as far as I'm away that only applies for things that can be swapped out underneath (i.e. are API and ABI compatible) without an application change. This is theoretically possible as something we could do but mostly people are requesting the ability to swap out things that aren't necessarily compatible.

Those things do happen with options, but I don't think it follows that eliminating options provides a better user experience. A formula that lacks needed options means the user makes their own tap, in which case...it will be built from source, not tested by CI, and provides new chances for failure. I.e., those three things that an option-using user currently faces will still be faced just about as often once options are eliminated.

I think a less flexible Homebrew/homebrew-core that works for every user every time is superior to a more flexible Homebrew/homebrew-core that works for every user 90% of the time. That's a product/design difference of opinion I realise we don't share.

Essentially, though, you touch upon a good point: for things that have to be built from source or build using options there's no real difference between Homebrew/homebrew-core and a tap that doesn't provide bottles. As a result it's much, much easier for the community to step up there and provide solutions to these problems without adding the negative perception when Homebrew/homebrew-core doesn't work and the issues that result from hard to reproduce, option, from source builds.

@zbeekman
Copy link
Member

@zbeekman zbeekman commented Sep 4, 2018

I think a less flexible Homebrew/homebrew-core that works for every user every time is superior to a more flexible Homebrew/homebrew-core that works for every user 90% of the time. That's a product/design difference of opinion I realise we don't share.

I personally tend to agree with @chdiza. (Although I'm willing to concede that I may be in the minority here, and I may not have had the extensive experience that led @MikeMcQuaid to those conclusions.) However, if we go this route, I think we need to greatly improve our documentation for setting up dedicated taps, with all the bells and whistles like bottling etc. I was looking into this a few months ago, and there is no straightforward guide on how to accomplish this. I finally stumbled upon this repository, which seemed like the best example for me to follow. Better documentation for users/contributors of the bottling process would make this type of migration much less of a bitter pill for some (like me!) to swallow.

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Sep 5, 2018

I think we need to greatly improve our documentation for setting up dedicated taps, with all the bells and whistles like bottling etc. I was looking into this a few months ago, and there is no straightforward guide on how to accomplish this.

The current documentation (e.g. https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap and the brew tap-new command in the manpage) is sufficient for many people to setup taps. If you would like to extend that documentation: please feel free.

with all the bells and whistles like bottling etc.

This doesn't really make sense; options are never bottled anyway so to remove them doesn't imply we need to provide an ability for others to bottle them.

Better documentation for users/contributors of the bottling process would make this type of migration much less of a bitter pill for some (like me!) to swallow.

The issue isn't documentation, really, it's setting up free building of macOS packages (on multiple OS versions) with free uploads to a free CDN. I don't think that problem is ours to solve, really, but again: if you're interested in solving it please feel free.

@zbeekman
Copy link
Member

@zbeekman zbeekman commented Sep 5, 2018

@DomT4
Copy link
Member

@DomT4 DomT4 commented Sep 5, 2018

For the record: I think the mass removal of options is patently ridiculous & achieves nothing except stymying debate about individual options because those PRs are too large to easily discuss just one or two elements.

I also think it is ridiculous to move ahead with this after 10 days of this issue being opened, when precisely two maintainers thus far have weighed in on the subject, and the core team as a whole was essentially rebuilt from the ground up less than one month ago.

Some of these options also have effectively zero maintenance burden, or have never been knowingly problematic in terms of either analytic-logged build failures or human reports, and yet get removed anyway. Other options were the product of days or weeks of discussions about how best to resolve other issues, like Perl binding versioning & incompatibility, and have been casually thrown out the window with zero debate.

I truly tip my hat to the "Ram the change through as rapidly as possible and hope most people, including maintainers, don't notice or object until it's too late" tactic.

@zbeekman
Copy link
Member

@zbeekman zbeekman commented Sep 5, 2018

@DomT4
Copy link
Member

@DomT4 DomT4 commented Sep 5, 2018

We’re all passionate here and care deeply about Homebrew. As far as I can tell no action has been taken yet.

#31847, #31830 & #31799. That's a lot of "no action".

@zbeekman
Copy link
Member

@zbeekman zbeekman commented Sep 5, 2018

#31847, #31830 & #31799. That's a lot of "no action".

Fair. I'm on the train and my internet connection is terrible, so I didn't do due diligence before I made that statement.

While I personally like options, and find that they add value to Homebrew for power users or devs who need a certain package built a certain way, I do see that there is a trade off and it's not a one sided issue. If it were put to a vote (I'm NOT saying the it necessarily should be...) I would vote to keep --devel and --HEAD options, and want to evaluate other packages on a case by case basis.

But anyway, I'd be curious to hear what other from @Homebrew/core think, if they have a strong opinion. There's a fairly good chance that they all agree with Mike which is why they didn't feel the need to comment here... 🤷‍♂️

@sjackman
Copy link
Member

@sjackman sjackman commented Sep 5, 2018

On the whole I'm not a fan of options for the reasons cited by Mike. I do like --HEAD, because it can be useful when troubleshooting upstream bugs. I don't see much benefit in going to the effort of removing options that have caused no documented trouble, either in analytics or issues. I'm in favour of removing options that have documented trouble. I'm in favour of adding no new options to formulae.

@fxcoudert
Copy link
Member

@fxcoudert fxcoudert commented Sep 6, 2018

@DomT4

mass removal of options

I'll be holding the open PR, and not opening new ones. I apologise if you felt those were rushed: it clearly was not my intention: I just got a little time to do cleaning-type stuff while I was sat at a conference, and took it. Given that: 1. the PR was open for more than a week, 2. it doesn't look much like a call for discussion, but a plan for action, and 3. no maintainer has objected, I figured it was OK to move forward.

I've tried to remove options from formulas with very few install counts, i.e. options removed should be lower than 0.5% in usage or lower than 5 in absolute install count (per 30 days).

@fxcoudert
Copy link
Member

@fxcoudert fxcoudert commented Sep 6, 2018

As to my personal opinion: apart from a few formulas where they are "natural" (aspell, some video or audio players), options run counter to our main goal, i.e. “just working”, for the arguments given by Mike. If we want to keep many options, I'd like us to consider running all option combinations through CI (which limits their number) or officially declare them “semi-supported” (i.e., we remove them when they break, unless someone patches it).

@claui
Copy link
Member

@claui claui commented Sep 6, 2018

I feel that keeping things lean and simple is a good thing. Also, existing documentation on maintaining a user tap is just fine.

What we could do better is advertise the user tap feature more often. As in, whenever options pop up as a topic in a PR.

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Sep 6, 2018

I truly tip my hat to the "Ram the change through as rapidly as possible and hope most people, including maintainers, don't notice or object until it's too late" tactic.
I don’t think bristly accusations are warranted

@DomT4 I strongly agree with @zbeekman: this was not an acceptable way to refer to the work of other maintainers such as @fxcoudert who received a PR approval before merging based on an open "help wanted" issue.

I also think it is ridiculous to move ahead with this after 10 days of this issue being opened, when precisely two maintainers thus far have weighed in on the subject
There is a degree of obligation on us maintainers to follow these proposals and issue tickets and voice our opinions.

Again, I agree with @zbeekman: this issue was open for 10 days in which you have been active on this issue tracker and in Slack and you had no comments on it during that time. You've also (re)joined the team more recently than @fxcoudert; he has no obligation to ask you for permission to make a change like this.

I'll be holding from the open PRs. I apologise if you felt those were rushed: it clearly was not my intention: I just got a little time to do cleaning-type stuff while I was sat at a conference, and took it. Given that: 1. the PR was open for more than a week, 2. it doesn't look much like a call for discussion, but a plan for action, and 3. no maintainer has objected, I figured it was OK to move forward.

I've tried to remove options from formulas with very few install counts, i.e. options removed should be lower than 0.5% in usage or lower than 5 in absolute install count (per 30 days).

You have nothing to apologise for @fxcoudert. It's worth noting we've not been accepting options on new formula for a long time now. When we imported formulae from taps (many of which were in our top 1000 and sometimes top 100) we've removed all options in doing so. This has resulted in dramatically fewer build errors and those formulae being easier to support.

To be extra explicit: this has been an undocumented but planned policy for several years.

What we could do better is advertise the user tap feature more often. As in, whenever options pop up as a topic in a PR.

@claui I agree.

Options in formulae don't produce a good user experience because they have to be built from source, we don't test them in CI and each combination of options provides a new chance for new failures to occur.

@fxcoudert Is the only person in this thread to even offer a suggestion of how to resolve any of these issues (run them all through CI). If someone points out an engineering problem like this: suggest an alternative solution.

MikeMcQuaid referenced this issue Jan 24, 2019
@jeroen
Copy link
Contributor

@jeroen jeroen commented Jan 26, 2019

The major issue we run into taps is that there is no way to give a tap preference over homebrew-core when it comes to dependencies. Even when the tap is pinned. This makes the situation on our build server very complicated.

For example in my case I need a version of poppler which does not depend on nss or qt. Because these have become hard dependencies in core, I provide a custom poppler in my tap.

However when brew installs poppler as a dependency of a core package (for example gdal in my case) it still installs the core version, not the one from the (pinned) tap. This differs from pinning in Debian, where a package from the pinned repo can be a drop-in replacement for the mainstream package.

This may seem small, but it makes the situation unmanageable. I need a few dozen modified formulas in my tap which are built with different options than core. This I can do, however brew keeps running into conflicts because it has already installed the core version of the same formula as a dependency.

I think if you expect people to run taps for customized formulae, brew should allow taps that provide replacements for core formula, and which get preferred even when installed as a dependency.

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Jan 26, 2019

The major issue we run into taps is that there is no way to give a tap preference over homebrew-core when it comes to dependencies. Even when the tap is pinned. This makes the situation on our build server very complicated.

This is intentional. We do not want to have random dependencies in our tree swapped out with versions that may not work.

For example in my case I need a version of poppler which does not depend on nss or qt. Because these have become hard dependencies in core, I provide a custom poppler in my tap.

To illustrate my example: if a package in Homebrew/homebrew-core relies on the nss or qt functionality: the custom poppler in your tap will break that package.

This I can do, however brew keeps running into conflicts because it has already installed the core version of the same formula as a dependency.

I've elaborated a bit on this here: Homebrew/brew#5615 (comment). I'm open to improving the docs to make this (i.e. use a different formula name) more obvious and well-documented.

@bumfo
Copy link

@bumfo bumfo commented Jan 26, 2019

So now, instead of copy-pasting homebrew options from Google, I need to use brew edit all the time when one single option would have solved my problem.

Even worse, editing formulas on my own is no better than the pre-homebrew age, when I read docs, carefully set up compiling options, and fail, and try again.

Popular Homebrew options are at lease given a chance to be tested and solved by the whole community. Without options, installing packages are only getting harder.

Please don't just remove all the options. Rather split the formulas into two taps, one ready-to-use out-of-the box (core), one with options that may not be tested fully, but can be improved together by the community.

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Jan 26, 2019

So now, instead of copy-pasting homebrew options from Google, I need to use brew edit all the time when one single option would have solved my problem.

The sites you're Googling will be updated with correct instructions.

Popular Homebrew options are at lease given a chance to be tested and solved by the whole community.

They aren't tested before updates: that's the reason for their removal.

Rather split the formulas into two taps, one ready-to-use out-of-the box (core), one with options that may not be tested fully, but can be improved together by the community.

This is what's happening except the latter is being maintained by the community outside of the Homebrew organisation.

@claui
Copy link
Member

@claui claui commented Jan 26, 2019

This may seem small, but it makes the situation unmanageable. I need a few dozen modified formulas in my tap which are built with different options than core. This I can do, however brew keeps running into conflicts because it has already installed the core version of the same formula as a dependency.

@jeroen Does Homebrew still give you conflicts if you use non-conflicting formula names in your tap (such as jeroen/core/custom-poppler), and control all the linkage manually (for now) via brew link/brew unlink?

@chdiza
Copy link
Contributor

@chdiza chdiza commented Jan 26, 2019

@jeroen I feel your pain on this. A solution I use is to put everything you need (even "mere" dependencies) in your own tap. Then just copy the HB formulas---even the ones you don't actually have to adjust the flags for---into your own tap, modifying the "depends_on" part as necessary to point explicitly to your own tap. E.g., put a formula for gdal in your own tap, and change it to say depends_on "myuser/mytap/poppler" instead of depends_on "poppler".

This means you won't get bottles, but that just goes to show why build-from-source package managers are Good and Necessary.

I have about 60 kegs installed, and now none of them are from the core tap. They are from my tap, which carries several duplicates of core formulas (except for their dependency references are changed to point at my tap). This way, I will never have the rug pulled out from under me by a sudden HB decision to mess with deps or flags.

brew should allow taps that provide replacements for core formula, and which get preferred even when installed as a dependency.

It should, but the above describes a way to ape this. Having to do brew install myuser/mytap/foo instead of brew install foo was mildly annoying, but e.g. I made an external command that will auto-insert the tapname before any formulas passed.

@claui
Copy link
Member

@claui claui commented Jan 26, 2019

Even worse, editing formulas on my own is no better than the pre-homebrew age, when I read docs, carefully set up compiling options, and fail, and try again.

@bumfo Would it help if Homebrew allowed you to write custom formula extensions, or some kind of formula patch, as @saagarjha suggested in a recent forum thread?

Here’s the relevant quote from this thread that outlines the suggested feature:

The benefits I get is that I the basic auto-updating portion is done by Homebrew itself, but whenever I build I run the “patch” (which I am imagining is something like me selectively copying the options I care about from an old commit to homebrew/core and telling Homebrew “here, apply this”) to customize it for my environment (transparently; the “patch” is applied each time a new update comes and brew update is run).

@claui
Copy link
Member

@claui claui commented Jan 26, 2019

I have about 60 kegs installed, and now none of them are from the core tap. They are from my tap, which carries several duplicates of core formulas (except for their dependency references are changed to point at my tap).

@chdiza Such determination! Given that you’re already going that route: have you looked at https://github.com/portage-brew yet?

(Not being snarky or something, I 100% mean it; I’ve only glanced at portage-brew briefly but it looks like a promising fork to me.)

[…] I made an external command that will auto-insert the tapname before any formulas passed.

That is actually a really cool idea.

@blogabe
Copy link

@blogabe blogabe commented Jan 26, 2019

@jeroen I feel your pain on this. A solution I use is to put everything you need (even "mere" dependencies) in your own tap. Then just copy the HB formulas---even the ones you don't actually have to adjust the flags for---into your own tap, modifying the "depends_on" part as necessary to point explicitly to your own tap. E.g., put a formula for gdal in your own tap, and change it to say depends_on "myuser/mytap/poppler" instead of depends_on "poppler".

This is what I've debated doing as well. I've resisted for the obvious reason that it places an undue amount of maintenance on our personal user taps and why a centralized tap can help.

One formula may have many - 20, 30, 40, ... - dependencies that I need to also manage and update. It's a burden I'm not stoked on taking on. Hopefully if portage-brew gains traction amongst the community then this should not be as much of an issue.

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Jan 26, 2019

This is what I've debated doing as well. I've resisted for the obvious reason that it places an undue amount of maintenance on our personal user taps and why a centralized tap can help.

I agree that centralising effort may be useful but disagree that this needs to be in the Homebrew organisation to be successful.

@blogabe
Copy link

@blogabe blogabe commented Jan 26, 2019

@MikeMcQuaid Don't disagree with you on this.

I think it may be easier and radiate a more inclusive feel for the end users, but it can work outside of Homebrew as well assuming enough power users the changes impact are willing to join and build up a critical mass.

We're good :)

@blogabe
Copy link

@blogabe blogabe commented Jan 26, 2019

My ignorance is showing, but is it possible to subscribe to a formula in core so that we can receive an alert if/when it undergoes an edit?

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Jan 26, 2019

Nope, sorry. Someone could build it on to of GitHub's APIs, though.

@jeroen
Copy link
Contributor

@jeroen jeroen commented Jan 26, 2019

This is intentional. We do not want to have random dependencies in our tree swapped out with versions that may not work.

I think it is the responsibility of the user at that point if I specifically decide to swap out core formulas from a pinned tap. We just need some way that makes it possible to install core formulas with another configuration than the default one.

The current situation make this very difficult. On the one hand you want core to be low-mainenance with little flexility (no options), more like Debian, which is OK. But then at the same time you prevent users from swapping out formulas with a custom build, as you would do in with a custom deb/PPA. So now there is no solution anymore for users that need a non-default configuration of a formula.

my example: if a package in Homebrew/homebrew-core relies on the nss or qt functionality: the custom poppler in your tap will break that package.

Most libraries won't change their API or ABI based on the configuration. Usually only certain features of the software will be enabled/disabled. Configuring a library with or without support for some driver/lib rarely affects how the program is called or linked, usually they can be swapped out safely.

Even if it would break a reverse dependency, at that point it is my own responsibility, not yours. But I do feel strongly that if you decide to remove all flexibility in core formulas to lower mainenance, you need to relax the requirement that core take precedence over all.

I've elaborated a bit on this here: Homebrew/brew#5615 (comment). I'm open to improving the docs to make this (i.e. use a different formula name) more obvious and well-documented.

A different formula name is really not a solution, then I would also need to add all reverse dependencies of the formula to my tap with a dependency on the changed formula name. This makes the problem an order of magnitude larger.

I think almost all users in this thread simply need some way to configure a core formula with features they need.. If options are no longer supported and you present taps as the solution, you should allow core formula to be swapped out with a custom one from a tap.

@voldemortensen
Copy link

@voldemortensen voldemortensen commented Jan 26, 2019

I've been thinking about this for awhile now. My first interaction with the Homebrew community has been pretty negative, but I'm going to put that aside and give this another try.

@MikeMcQuaid, would you be open to the idea of an "override" tap? This would functionally be the same as a custom yum or apt repo.

The way I'm thinking this could work is that a user would specify a tap (or taps) that would be checked prior to checking the core formulae. Formulae installed from the "override" tap would satisfy the dependencies of core formulae. This would allow a user to substitute in a custom formulae, but also allow Homebrew to offload the support requests to tap maintainers. This would also help a third party tap aggregate common custom formulae into one tap.

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Jan 26, 2019

@MikeMcQuaid, would you be open to the idea of an "override" tap? This would functionally be the same as a custom yum or apt repo.

@voldemortensen We have custom repositories (taps): https://docs.brew.sh/Taps. These can be pinned with brew tap-pin.

Formulae installed from the "override" tap would satisfy the dependencies of core formulae. This would allow a user to substitute in a custom formulae, but also allow Homebrew to offload the support requests to tap maintainers.

This will not work because these formulae will end up breaking core formulae in ways that are hard to debug (e.g. missing symbols/libraries) and we will have to be the ones fielding those support requests.

You can create your own taps with your own formulae that are installed however you like. You can't inject random formulae as dependencies for the ones we test and build and expect them to work.

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Jan 26, 2019

I think it is the responsibility of the user at that point if I specifically decide to swap out core formulas from a pinned tap. We just need some way that makes it possible to install core formulas with another configuration than the default one.

@jeroen Regardless of whose responsibility it is: we will be the ones receiving the bug reports so we'd rather not add functionality to increase our support burden, sorry.

The current situation make this very difficult. On the one hand you want core to be low-mainenance with little flexility (no options), more like Debian, which is OK. But then at the same time you prevent users from swapping out formulas with a custom build, as you would do in with a custom deb/PPA. So now there is no solution anymore for users that need a non-default configuration of a formula.

Debian doesn't provide the same degree of user accessible support on GitHub if you have a package that breaks.

We definitely do support swapping out formulae but we do not support swapping out the dependencies of formulae because, as I mentioned in the last comment: they will break.

So now there is no solution anymore for users that need a non-default configuration of a formula.

Yes, there is: maintain your own version of the formula in a tap. As noted in Homebrew/brew#5622 the best way to do this is to use a different name so they can live side-by-side. This has been successfully working with e.g. the nginx-full formula for many years.

Most libraries won't change their API or ABI based on the configuration. Usually only certain features of the software will be enabled/disabled. Configuring a library with or without support for some driver/lib rarely affects how the program is called or linked, usually they can be swapped out safely.

"Most", "usually" and "rarely" add up to a non-trivial number of support requests at Homebrew's scale. We're not willing to support that.

Even if it would break a reverse dependency, at that point it is my own responsibility, not yours. But I do feel strongly that if you decide to remove all flexibility in core formulas to lower mainenance, you need to relax the requirement that core take precedence over all.

Again: regardless of whose responsibility it is: we field the support requests so it ends up adding extra work for us.

Core formulae remain the primary option because they are what is used by the vast majority of users. The majority of users configurations are now handled by the defaults we chose for the software in Homebrew/homebrew-core now.

A different formula name is really not a solution, then I would also need to add all reverse dependencies of the formula to my tap with a dependency on the changed formula name. This makes the problem an order of magnitude larger.

I think almost all users in this thread simply need some way to configure a core formula with features they need.. If options are no longer supported and you present taps as the solution, you should allow core formula to be swapped out with a custom one from a tap.

Again: we do allow these formulae to be swapped out but not as dependencies of existing formulae.

I don't think we can really continue discussion indefinitely on this closed issue. Where's there's specific requests for things that make life easier for tap authors without making things harder for the Homebrew maintainers: we have and will help. Where PRs are submitted that make life easier for tap authors: we will review them and may merge them.

Finally, it's worth remembering that the Homebrew maintainers do not need to do anything. In fact, open source maintainers owe you nothing.

If you want some functionality we are not willing to support: you need to be willing to do the work yourself (which may be more work than you wish given our constraints) or you need to accept what we're willing to provide you (for free, in our spare time).

@jeroen
Copy link
Contributor

@jeroen jeroen commented Jan 26, 2019

You can create your own taps with your own formulae that are installed however you like. You can't inject random formulae as dependencies for the ones we test and build and expect them to work.

That's exactly how PPA's work in Ubuntu/Debian and it's fine. It's the only way to customize a formula if you don't want to support options in core formulae. Users that choose to swap out core libraries with a custom tap probably know what they are doing. It's not your responsibility to debug this.

However your current policy of hardcoding a single config for all core formulae and at the same time not providing any way to swap them out with a custom built, is obviously leading to frustration by many users for which the default configuration is inappropriate.

@MikeMcQuaid
Copy link
Member Author

@MikeMcQuaid MikeMcQuaid commented Jan 26, 2019

That's exactly how PPA's work in Ubuntu/Debian and it's fine.

It's not exactly how they work because they both ship binaries and Homebrew/homebrew-core ship binaries but taps/options ship source builds.

Even if it were literally identical: It's perhaps fine to them/you but t's not fine to us. It will create bugs that are not immediately obvious, it will create user confusion and it will create extra work for us (even if we could instantly detect these issues and close them).


I'm relocking this thread in favour of our Discourse forum for more general discussion and specific issues (e.g. emacs cask and formulae conflict
https://github.com/Homebrew/homebrew-core/issues/363109 or specific regressions with new options
#36342) or PRs that add functionality to Homebrew/brew or make change the default build in Homebrew/homebrew-core when relevant.

@Homebrew Homebrew locked as resolved and limited conversation to collaborators Jan 26, 2019
@claui
Copy link
Member

@claui claui commented Jan 26, 2019

I’ve reopened the Discourse thread Maintaining a tap to provide options for a formula to discuss possible PRs that help tap authors do their work with less friction.

@bumfo Feel free to follow up there if you wish.

MikeMcQuaid referenced this issue Jan 28, 2019
iMichka referenced this issue Feb 19, 2019
SMillerDev referenced this issue Feb 22, 2019
Closes #36066.

Signed-off-by: Chongyu Zhu <i@lembacon.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Homebrew TODO
  
Done
Linked pull requests

Successfully merging a pull request may close this issue.

None yet