Maintaining a tap to provide options for a formula

(Saagar Jha) #1

I was surprised to learn today that Homebrew has apparently decided to drop support for formula options, a feature that I use relatively often. In my case, I have both parallel and moreutils installed, and the two conflict, so I used to install with the --without-parallel option passed to brew install moreutils to deal with this. Since the issue has been locked and I cannot comment on it anymore, and I can’t find a place on GitHub to continue the discussion (the homebrew/core issue template seemed to be very clear in telling me that this was not welcome there), I was wondering if someone could help address my concerns here, particularly with the solution provided in that thread:

  • How do I replicate the old behavior for my own personal use? As a quick summary, the behavior I had before was that I ran brew install moreutils --without-parallel once, and after that whenever I ran brew update I would always get an up-to-date version of moreutils that did not conflict with parallel automatically, with no effort on my part. I have read the instructions on how to make a tap, but this doesn’t seem to solve my problem. Sure, I might set up a tap (which is slightly annoying but not awful; it’s just extra work that I’m fine with doing if it’s a one-time thing), but I don’t see a way to keep this up-to-date. Can I “track” a homebrew/core tap and have mine automatically update as that one does? Because otherwise it seems like I need to follow the development of parallel and manually update the tap every time a new version comes out, which kinda defeats the point of using a package manager :wink:
  • Does everyone have to do the work I outlined above to maintain taps? Say, for example, I run a tap for moreutils --without-parallel; is there a way to save other people the work of having to do this themselves? Say, an official, centralized location for it, or a way of verifying authenticity? Because otherwise I see everyone duplicating this work for themselves, or (more likely) relying on saagarjha/moreutils-tap-which-is-subtly-sketchy out of laziness.
  • What will the process be for migrating old formulae? Currently, it looks like there are commits going in to silently remove options, which causes breakage for end users (like me!). I don’t think you can expect everyone to go comb through homebrew/core’s issues to figure out why their package no longer works, find the thread where this was discussed, and then locate a replacement. So will there be a way of telling people where they should get their new formula from?
(Sean Molenaar) #2

Unfortunately there’s no such options. If you want to maintain something homebrew-core doesnt support you’ll be on your own.

(Saagar Jha) #3

So just to make sure, there isn’t really any intended solution in this case? I’m surprised to see that this wasn’t discussed when the decision to remove options was being made, since this seems like a relatively simple issue to foresee in advance. As I’ve mentioned above, none of the “solutions” seem to provide a good experience (regardless of claims that “it is very easy for users to maintain a tap”, unless I am mistaken–but from your response, it doesn’t look like it), and one could say that the recommendation to rely on third-party taps isn’t particularly good advice from a security perspective…

In short, I think that the changes that this entailed needed more discussion from users–it’s not a very pleasant experience as an somewhat technical end user to find that a regular brew update has broken a tool that they rely on, have to dig through GitHub to figure out what is going on, and find a locked thread discussing the change that brings up issues that seemed to have been brushed aside, which they had no knowledge about until it came into effect and were not even able to weigh in on. I’m sure this wasn’t the intention, but the feeling I got from that thread was that the input of Homebrew’s users wasn’t very welcome :frowning:

(Sean Molenaar) #4

The input was welcome months ago when the issue was being discussed. The majority of users doesn’t use the options that were removed though (we’re talking roughly 1% in analytics or less) the case if you want to modify a formula is the same as for all other instances of brew formula though, there’s no support from homebrew core. The solutions you provide would all entail that there’s still support by homebrew-core, just more complicated than before. And simplification being one of the main reasons for this change that is just not going to happen.

(Saagar Jha) #5

That’s my point: I had no way of knowing that this was even being discussed, despite being in the group of people that would be directly affected by the change; the first I ever heard of it was when my packages suddenly started breaking. It would have been really nice to notify users that this was being considered, invite them to participate in the discussion, or even just have a warning that this feature was going away to allow them a solid plan for migration–something to make this change not blindside users far later than they could weigh in or prepare for it. Honestly, if I had seen this in my console two months ago:

$ brew update
moreutils 0.62 -> 0.63
==> Upgrading moreutils
Warning: Homebrew is planning on deprecating options soon.
 For more details, see

I would have been much more willing to go along with the change, since it would afford me a chance to bring up my concerns and have the discussion I’m having with you right now (making it much more likely that solutions would be considered).

While I do appreciate the fact that I have no right to dictate how the Homebrew maintainers should spend their efforts, I feel that this is a poor metric to use. First of all, by removing options, you’re removing popular formulae that hundreds of thousands of people rely on; just by glancing at the analytics (which, of course, is predicated at the fact that they are an accurate assessment of the state of Homebrew’s community, which I doubt given that those opposed to the gathering of this data are much more likely to be advanced users who know how to disable analytics) it’s clear that this list includes popular formulae such as yarn --without-node, vim --with-override-system-vi, emacs --with-cocoa, and of course moreutils --without-parallel (among a thousand others). IMO your limit is set extremely high: I’m sure that significantly fewer than 1% of users install ed, but it would be ridiculous to suggest removing it from Homebrew (interestingly, this formula is less popular than any of the others I have listed above, as well as ed --with-default-names).

I’m not sure what you mean here.

Ok, let’s assume that the current decision to remove options can not and will not be git reverted, which seems like the likely scenario. At this point, these “variants” are gone from homebrew/core; there is no support because the packages no longer exist at all. What I am asking for is not the support of homebrew/core; rather, I am asking for a replacement for two things that homebrew/core had: a way to keep packages up-to-date without requiring individual users to track projects themselves, and a centralized, verified system for getting formulae–both which are fundamental features of a package manager, and qualities which the “solution” of users making their own taps lack (again, unless I am misunderstanding, but I am coming to the sad realization that I am not). In particular:

  • User-taps do not seem to have the ability to auto-update, as homebrew/core optioned formulae did (as in: there is someone other than me doing this work, often the author of the project themselves or a core maintainer pushing these changes; they are clearly more reliable than I am at making sure the formula is up-to-date). Whenever I want a new version with a tap I make myself, I need to manually update my tap, rather than just running brew update; brew upgrade–at this point, I might as well just poll the website for new releases by hand and install use its installer to get new versions.
  • User-taps have no guarantee or vetting process to verify that they are legit. I could very well upload a tap to GitHub that was malicious, and most people would tap it without a second thought provided that my tap was the first solution they found. With homebrew/core, there is a “quality control” process is centralized and robust.

My ideal solution for this, given our constraints, is to have some sort of centralized homebrew/options repository for formulae with options, which frees homebrew/core from having to deal with support, but allows people to step in to maintain formulae they care about when it breaks (which, when compiling from source, is not actually that often for many formulae; most of them don’t change that much!) and share it with everyone else. The centralized nature prevents people from going into the “wild west” of GitHub and picking the first thing they find that gets them the formulae with options they want.

Less desirable, but still possible, is a way for me to apply a “patch” to any formulae specification files coming from homebrew/core to add options and giving me the ability to have auto-updating formulae that I customize for my system, but otherwise don’t have to touch until it breaks. This, of course, makes everyone do their own work rather than being able to rely on other people, but doesn’t have the other issues I have outlined above.

So really, I don’t see how this is any “support from homebrew/core” here. We continue with the expectation that things can and will break, but accepting that issues will get filed for them and people that care enough will go and fix them. Nobody is “forced” into supporting anything.

(Sean Molenaar) #6

There is a public issue tracker, you could have spotted the issue there.

The 1% is per formula. If > 1% of all users of a given piece of software use an option that would be a reason to not make it a default. But all options were considered on a case-to-case basis. (some simply don’t add much overhead)

The situation for options isn’t much different from other software that isn’t in homebrew-core, it’s just not supported. It’s not a special case.

This is exactly right, if you want to use something unsupported you’d have to do your own updates.

They don’t have to, if you want to spread malware through brew it won’t be allowed in homebrew-core but what you do with your own install is up to you.

This would mean homebrew-core would be copied and instead of reducing the maintanance burden it’d be doubled, simply because some people want to use homebrew in configurations that very few people would benefit from.

If you’re willing to write the full implementation of what’s essentially “child formulae” I’d happily review it.

Wouldn’t you agree that the time of homebrew maintainers is better spend helping the majority of users instead of the tiny minority that uses these options? You can check the github page but “people that care enough” is usually homebrew maintainers, who also respond and investigate issues. There’s a lot of support involved in simple issues and as you said, nobody is “forced” into supporting anything but you do like to get a response to a post, even though I’m not forced to.

(Joshua McKinney) #7

To put it bluntly, and with all due respect and acknowledgment that you’re doing a great job, but that’s a BS perspective. I’m thankful for all the work the core devs put in here, but communicating this out to users should have been priority number 1. I’m a dev that has contributed to core and a few casks in my time. I was also blind sided by this. The first I heard of it was the 1.9 blog post.

Yes it might be 1%, but have you checked how that overlaps with your contributors?

I support the idea of making options possible again, but in a way that makes it clear that support is not coming. Perhaps a homebrew-replacements or homebrew-unsupported repo with the chilld patch approach could work.

(Sean Molenaar) #8

Anything coming from the homebrew organization on Github would still suggest support. Thats a large part of the issue and also the reason why only usage is being removed, not the feature in general. Homebrew is not a company but is volunteer run and just the effort that goes into explaining people why we don’t want to support their options tells me this was a good call to reduce the support burden.

(Joshua McKinney) #9

I’m glad the feature is sticking around. I was under the misapprehension that it was going away entirely. That makes more sense. Probably don’t even need code for “child formulae” a custom tap and some sort of lambda that reacts to the main repo changing and applies patches would do the trick.

@saagarjha are you up for it? I think the problem still becomes knowing how to adequately and securely manage those patches.

(Claudia) #10

To put it bluntly, and with all due respect and acknowledgment that you’re doing a great job, but that’s a BS perspective.

In my world, telling a maintainer that their perspective is bullshit is the exact opposite of respectful behaviour.

I’m thankful for all the work the core devs put in here

Thank you. I appreciate user feedback, be it positive or negative, even though we may disagree on many points.

communicating this out to users should have been priority number 1.

While you have a very good point in that we could do a better job in communication, I still feel we have done our best in prioritizing. Sometimes, an org needs to prioritize staying functional and avoiding burnout over anything else.

1 Like
(Mike McQuaid) #11

“a BS perspective” is not respectful. Please reread our Code of Conduct adjust your future communication accordingly.

Communication, like many part of Homebrew, could be improved. Who is going to do that, though? What you (and others) seem to ignore about requests for additional communication is that you’re actually asking that more work be done by the individuals who are already overstretched (i.e. me) about a change that you fundamentally reject anyway.

We’re not willing to ship things we don’t support, sorry. I do not consider it acceptable to ship software that we are unable to test and we know will break. Even if I did consider that acceptable I’d be unwilling to accept the additional support burden that the maintainers have to take on from people submitting issues when they are clearly told not to (something that still happens often).

In short, read through and if you have suggested to solve the problems that are mentioned there (e.g. maintainer and CI resources, inability to bottle options, inability to test options) then I’m all ears. With all due respect, though, you’ve contributed some pull requests (which I genuinely appreciate) and I’ve been maintaining this package manager for 10 years. I don’t make up problems and in the last year there’s been several occasions where this project has run a real chance of dying completely; changes like this are how we are going to be able to keep it alive while being run in the spare time of volunteers.

1 Like
(Mike McQuaid) #12

Please consider reading the issues linked from the release notes if you are going to complain about them which would have explained this. Somewhat relatedly, it’s a little ironic to complain about poor communication on our part and not read the communication we have made…

To be clear: like brew extract we want to make it as easy as possible to maintain these formulae in taps. We are open to Homebrew/brew changes in order to make that process easier.

(Saagar Jha) #13

(I apologize in advance if my post seems a bit disjoint; I had started writing this when @SMillerDev replied to my comment and then I stepped away, so it’s kind of in a weird state where I tried to take my original comments and merge in the new developments.)

I don’t agree with the way @joshka said it, but I do agree with the point he brought up: the communication around this has quite lacking. When contributors to Homebrew (a group which I am part of, if only barely) know nothing about this change until it’s already being implemented, I think there’s at least some issue here. I’m reminded of this exchange from The Hitchhikers Guide to the Galaxy:

Mr Prosser: But, Mr Dent, the plans have been available in the local planning office for the last nine months.
Arthur: Oh yes, well as soon as I heard I went straight round to see them, yesterday afternoon. You hadn’t exactly gone out of your way to call attention to them had you? I mean like actually telling anybody or anything.
Mr Prosser: But the plans were on display…
Arthur: On display? I eventually had to go down to the cellar to find them.
Mr Prosser: That’s the display department.
Arthur: With a torch.
Mr Prosser: The lights had probably gone out.
Arthur: So had the stairs.
Mr Prosser: But look, you found the notice, didn’t you?
Arthur: Yes yes I did. It was on display at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying beware of the leopard.

Sure, I technically had a chance to comment, but it was in a place that I had no reason to know the location of, and even now had to dig through GitHub to find. Putting the discussion in a public place (actually, that’s not quite true: apparently some of this happened in Slack?) and expecting to get feedback doesn’t seem like it would really work. I’m actually surprised you got feedback at all, actually, but then again most of the conversation came from the maintainers and a couple of contributors…

I don’t see where you getting that number. Unless I am not understanding the install analytics correctly, for the examples I posted, this ratio is over 10%, going up to 70% for ed --with-default-names. I am still not seeing the case for these use of options being uncommon; it seems like any way I look at it the ratio is signficantly more than 1%.

There is a huge difference between a popular program already in homebrew/core like moreutils, but installed in way so that it doesn’t conflict with another popular package, and a toy shell script that I want to share with my friends who use Homebrew or really any other package not found in homebrew/core. There are difference in number of users is multiple orders of magnitude, for one, and it’s confusing to find the same package in the official tap but also a popular “fork” in another random place. I really do think that these two should be treated differently; not as a “special case”, per se, but still be recognized as something that people use.

I think this is lacking the context in which I wrote it. The person doing the work here is not me or the Homebrew maintainers, but the author/interested user of the project the formula installs. Previously, they would have a centralized place where they could make sure their project was available on macOS, but now there is no reason they would go to saagarjha/tap-with-options in addition to homebrew/core. The work that was being done before in a central place no longer gets applied everywhere else.

Again, I’d like to reiterate that I appreciate the work that the Homebrew maintainers put into the project (having a PR already open to fix a formula so I don’t need to look at it, which has happened to me multiple times, is really great), and, considering that I use Homebrew, I have a vested interest in keeping it alive and working as well as possible. While I was not entirely aware of the recent issues Homebrew has run into, I can empathize with your viewpoints, having maintained or participated significantly in the development of other popular open-source projects I am keenly aware of the work that maintainers must do, and having to tell people that we don’t have the time or energy to implement something that they wanted. That being said…

…this makes me a bit sad. I am not trying to exasperate you with calls of “bring back the options”, and I hope I have not come off that way with my responses here. My intent was to bring light on points that I felt were not adequately touched upon during the discussion of the issue, try to get a better understanding of the reasons why it was implemented, and lament the fact that it was quite difficult for me to provide input in the hopes that more avenues for communication will open up in the future; namely, notifying affected users to comment on the discussion and have a longer “deprecation” period, and keeping sources close to the conversation open and being clearer in indicating a place to provide feedback–when I tried to extend discussion on GitHub, I was prevented from doing so on the original thread, nor was I comfortable opening a new issue and link back to the old one due to the frankly scary issue template.

That being said, I still think that the current solution is going too far in the other way and ends up having more of a negative effect than it should, and I think that there is a compromise solution somewhere that we just haven’t gotten to yet that would end up being much nicer for everyone. Would you mind qualifying your issues a bit more, specifically with regards to the maintenance burden of supporting options, as well as what you consider to be “acceptable” for Homebrew and minimizes support requirements? As I see it, the benefits we are losing by going this route are mainly focused around convenience and customizability for users, at the cost of a higher maintenance burden. I have come up with a couple ideas in this thread, and was wondering how feasible they would be considering the constraints you have; it seems like any taps under homebrew/ is off limits because it would cause people to open issues, and Homebrew does not have a good way of preventing people from filing issues on things marked as unsupported? How much CI was this using up, and can Homebrew spare any at all? AFAIK Homebrew tests every binary bottle, to what extent does this coverage go, and are builds from source also included? How many combinations are considered reasonable to test, and will anything outside of this be removed at some point? How much complexity was being added by this change (I’m not great with Ruby and as such haven’t touched the core of Homebrew, so I’m not unfortunately not very aware of this)? What was the support burden?

Would you accept functionality for Homebrew to do anything like distribute the source code of the formula (which it is doing anyways, since --HEAD seems to be a thing that will continue to exist), and allow me to compile my own package with relevant options? 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). Is it reasonable to expect that people working at this level of Homebrew will know enough to not file issues for the issues they encounter?

Again, I appreciate the feedback that you have given me, and I hope that it’s possible to improve the situation we have currently to benefit everyone. Finally,

If we end up with something here that I could reasonably implement, I’d be happy to contribute, as long as I can understand the Ruby :wink:

(Mike McQuaid) #14

When we remove options we adjust the defaults to best fit how people are using the application. In many cases this results in the defaults being changed to include things that were options.

Yes. This is because the people who do the bulk of the work to run the central place are not willing to ship options any more.

You’ve been able to provide input here. When it comes to “better understanding the reasons” unfortunately that’s another request for time from already busy maintainers.

There is not. I’ve searched long and hard for one and solicited many suggestions and found nothing.

We do not support people who wish to build from source, no.

In terms of the other numbers/details requested: you can browse around but I’m afraid I/we can’t justify the resources to gather that information. It’s a non-trivial endeavour.

Unfortunately it is not reasonable. People have been warned in the past and continue to do so.

Something like this seems like the best fit. Right now I think you might be able to subclass an existing formula and override the install method to handle any options you use.

1 Like
(Saagar Jha) #15

I’m assuming that the general guideline for this would be to pick the option that the majority of users use, but this still leaves out a significant number of users if the “option/no option” ratio is near 1:1, as is the case with many packages. What is the plan for formulae like these? Will everything with >1% usage end up being split into two (or more, in particularly divided cases): formula and formula-with-options-applied?

This response is starting to frustrate me, since every time I bring up “centralized work” the response seems to always be “we are doing this work for you and therefore don’t have to listen to you”, which is a true statement but is also a misunderstanding of what I am trying to say. My point is that the Homebrew maintainers and collaborators are already doing the work to keep packages up to date, and they are doing so in a way that is central: homebrew/core. I do not see it controversial that they will continue to do this job, since without it Homebrew would not function at all.

Your argument seems to be that options were causing an unduly burden on maintainers which they did not want to deal with, and I am willing to accept that this as true. However, I do not see why you not wanting to have to deal with options means that I, as a downstream user of your software, can’t use the work already being done to keep formulae up-to-date and extend it locally (specifically: in a way that should not affect homebrew/core’s day-to-day development) to simulate options. The reasons why I’m forced to bother you about it here is that it doesn’t look like Homebrew currently supports the “hooks” into the build process that I would need to simulate this feature locally, so I am trying to argue that these should be added so I could go and write my own “patches” without having to get anyone from homebrew/core to continue to support it.

I only asked for this information because I assumed that you must have gathered it already to measure the benefits of removing this feature, because as far as I can tell one of the arguments to remove them was because they kept breaking due to a lack of CI resources to test options.

With all due respect, I am finding it difficult to believe that you have not been able to find any solutions for this. You are saying that it is fundamentally impossible to make something that is advanced enough that it will prevent people who are willing to waste your time repeatedly filing issues about formulae breaking in unsupported configurations when told not to, which to me seems quite far-fetched: are you anticipating to be overwhelmed with users that say “I tried brew install formula on my Mac OS X 10.3 system but it didn’t work so I used Homebrew to get the source and and dug into Homebrew’s obscure compilation modification feature and used it to coerce the linker into producing executables for PowerPC, but I messed it up and now I’m going to repeatedly forget how to read and ignore half a dozen warnings to not file an issue for this and waste your time”? The people using this feature are going to be somewhat advanced users, even more so the more we push this on users to implement themselves. They are competent enough to know that they shouldn’t be filing issues for problems that are clearly “on their own” to fix.

Again, does this allow me to only have to deal with writing options, and not have to handle updates? Because I fundamentally cannot keep track of the release schedule of every package I use; the main reason I use a package manager is so that I can reuse the work of the dozens of people who contribute to the main repository. I am totally OK with writing a custom install step, options, whatever, as long as autoupdating is not something I need to reimplement.

(Sean Molenaar) #16

With all due respect, I am finding it difficult to believe that you have not been able to find any solutions for this. You are saying that it is fundamentally impossible to make something that is advanced enough that it will prevent people who are willing to waste your time repeatedly filing issues about formulae breaking in unsupported configurations when told not to, which to me seems quite far-fetched: are you anticipating to be overwhelmed with users that say “I tried brew install formula on my Mac OS X 10.3 system but it didn’t work so I used Homebrew to get the source and and dug into Homebrew’s obscure compilation modification feature and used it to coerce the linker into producing executables for PowerPC, but I messed it up and now I’m going to repeatedly forget how to read and ignore half a dozen warnings to not file an issue for this and waste your time”? The people using this feature are going to be somewhat advanced users, even more so the more we push this on users to implement themselves. They are competent enough to know that they shouldn’t be filing issues for problems that are clearly “on their own” to fix.

You’d be surprised how often this would happen. The first people might be advanced users but then someone posts it on stackoverflow and suddenly everyone is an expert and files issues for it.

In the end you just have 2 options, deal with the lack of options and have support from homebrew-core or make your own version and don’t have the support. Subclassing something in the ruby files might work with keeping the updates but in the end, none of the maintainers would provide active support for such a hackaround.

(Mike McQuaid) #17

We will not be creating duplicate formulae unless we’ve needed them with contradictory options (see curl-openssl). People will need to maintain less widely used options in taps.

Because if we continue to keep the options in formulae we need to continue to deal with the support issues that result (and we’re not willing to do that).

I am open to adding hooks to make it easier to maintain formulae with options in taps.

It’s not respectful to (indirectly) accuse of me of having found solutions but lying about having done so, sorry. Regardless, you don’t need to believe me because it doesn’t really matter either way and the end result will not change.

They should be but they aren’t so: here we are

I have no idea, I haven’t tried it.

If you wish to reuse their work you will have to accept (such as in this case) that their decisions on how the package should be built will differ from yours and you then have a choice of doing the work yourself or accepting their versions. Note this is how pretty much every other package manager works.

So where we’re at: we’re removing all options for formulae in Homebrew/homebrew-core in the near future. Options will need to be maintained in taps. I will review and help with (to an extent) PRs that make that process easier for you and for others to maintain those taps but I will not be doing most of that work by myself.

1 Like
(Saagar Jha) #18

Likewise, I don’t think it’s particularly nice to misconstrue what I wrote into something where I’m calling you a liar; trying to hunt for oblique rudeness does nothing other than lower the overall quality of conversation and drag it into personal attacks, which is a place that I would very much rather not go. I’d appreciate it if you took the time to consider my comments in good faith, and you’ll find that in this case the quote you pulled, out-of-context, makes a lot more sense when you consider the circumstances: you have laid out certain points that you claim to refuse to compromise over (namely, building from source/allowing customization and preventing people from filing issues), ruling out the suggestions I make (as well as those brought up before), but seemingly accept the current policy which has its own issues in these areas.

OK, so I’m going to have to ask for clarification here: from the responses I’m getting, it seems like homebrew/core doesn’t want to deal with any issues involving unsupported configuations at all. However, this is clearly unfeasible: there is nothing stopping someone from reporting an issue with my tap to homebrew/core, nor is there a lack of people currently posting issues about their formulae not working because of this change (most of which end up getting a response like “wontfix, look at #31510”). Clearly, there is a number of issues that you are OK with handling, and this number is greater than zero. So my question is what this number is, to allow me to come up with a solution that generates fewer issues than this amount. Usually, this manifests itself as having users follow more steps to get to a state where they can mess up; as a core maintainer of a quite popular project I have found that the more advanced features get significantly fewer bug reports filed against them, regardless of the existence of Stack Overflow or any other support forum.

No, this just isn’t true at all; basically every other package manager that I’m aware of differs from Homebrew in this regard. Off the top of my head, MacPorts and APT both

  • provide different versions of packages
  • provide variants for packages
  • allow for compiling packages from source locally
  • allow the user to control how to compile their packages, offering options like passing in custom environment variables

Homebrew has been moving away from offering this functionality (though, it still does allow for building formulae from source, just not in a way that is customizable) and towards being more like a binary distribution service, so it’s basically alone here.

I’m glad to hear it. If we can figure out something that provides measurable improvement in the area of allowing users to customize their formula installs in a way that is acceptable to Homebrew’s maintainers, I could try my hand at implementing this.

(Mike McQuaid) #19

Alternatively, I found something you said to be rude and somehow it’s justifiable to blame me for that rather than apologising. Ok then!

Sorry, no. This thread has had way more clarification and explanation than is necessary and, at this point, a good use of time.

It is very far from alone but: yes, we’re a binary distribution now and that’s intentional.

Please do. Until then, I think we’ve exhausted this topic, thanks.

1 Like
(Mike McQuaid) closed #20