Is that me? Cool. Right. Can everyone hear me? Is the mic working?

Just for the recording. Oh, just for the recording. Gotcha. Cool. Thank you for coming everyone. This is, I'm going to try and stand here mostly because my beeper is not working. Unfortunately, I can't do anything except laser you with it. So, I'm going to talk today about Homebrew 2.0. Starting point, who's heard of Homebrew?

Anyone in the room? Cool. A few people. Who uses Homebrew? Again, probably the same. Who here has submitted a pull request to Homebrew ever? Nice. Who here maintains Homebrew? Hey, there's more than just me today. Exciting. Thank you.

Anyone submit a PR to Homebrew and had it rejected by me? Only maintainers, that's okay. That's fine. That's fine. Cool. And then we also have, who likes our new logo? In fact, no. A tougher question. Who can tell the difference between our new logo and our old logo? It's basically the easy way to tell, in case you're wondering if you've got a vintage

logo sticker on your laptop, is the new logo has a straight beer glass sides instead of overly curved one. We have one of the Homebrew cast maintainers full-time job as a designer. In fact, is Vitor in the room? There, Vitor. Hello. We've not met before.

Hello. Yeah, so he sent me a list of corrections of why their old logo didn't meet standards. Now we have a nice new logo with more accurate beer glasses so you don't get confused and think that you're drinking when you're Homebrewing or vice versa or whatever. Anyway, so, who am I? My name is Mike McQuaid. Thank you very much for having me here.

My worlds collide often because I both work at GitHub and work on Homebrew. My job at GitHub is not to work at Homebrew. That's a kind of happy side effect. As a result, I'm often telling people, sometimes diplomatically, sometimes not, in GitHub everything that I kind of want GitHub to do better for open source

and then vice versa, sometimes defending stuff that GitHub has done to Homebrew maintainers who are grumbling about it when it happens. Yeah, so if you want to talk to me about Homebrew or open source stuff or whatever, you can get me on Twitter. You can find my email address on my website and stuff like that. And I'm always happy to talk more about this type of stuff. I've been working on Homebrew for about ten years.

This year, I guess, ten calendar years at least. I'm working for GitHub for about five. So, yeah, I was a happy GitHub user before I worked there. So, I'm somewhat less biased than I might sound. We released Homebrew 2.0 yesterday, like I was sitting in the...

Thank you very much. In the cafeteria, which was nice. It felt satisfying to actually tag the commit and submit it whilst here. So, yeah, I wasn't sure when we were going to release this. So, because I did it yesterday, I figured we could do in this talk some of the things

that my top ten features, I guess, that we've shipped in Homebrew 2.0. Some of these things are not... So, the difference between 1.9 and 2.0 were relatively minimal. Most of these things were all things that I kind of wanted to see us do before we would call ourselves 2.0. It's kind of fun because, I guess, this time, two years ago,

I was doing the same talk about Homebrew 1.0, which had been released a few months before. So, it was a fun little game going back and comparing the notes from a few years ago and seeing what we've done in that time period and what things we've changed and what we haven't and all this type of thing. To make it more of an adventure, what I'm going to do is I'm putting up pictures that are loosely related to the features,

and then we're going to see if you can guess what the feature is. Homebrew maintainers, you are not allowed to guess. Right, so, the first one. Anyone guess? Support, yes.

So, that is a picture of a... I know it looks like it's an actual photograph, but I did modify that myself. That is a picture of a mountain lion, which was RSX 10.8, and it is crying because it is no longer able to run Homebrew. So, it's a little bit weird, it's like a feature, but the main thing, I guess, many of you here work on software projects

or open source software projects yourselves, and that allowed us to delete enormous amounts of legacy code, because versions pre-mountain lion and below ship with now really, really old compilers that don't support C++ 11, don't support C++ 14, and stuff like that. The Xcode shipped separately to the combine line tools,

and sometimes the system came with X11, tar didn't come with LZMA support, and yeah, basically all these things that mean that you can remove a crap load of if statements all over the code, which makes me happy. So, the next one.

Yes, so, the options. This has been a little bit contentious recently, I don't know if you've noticed. So, in the Homebrew core repository, we now don't provide options on packages. Again, this seems like a weird thing. I'm starting with the horrible features that aren't really features for anyone except maintainers first, and then we'll build into the nice stuff later.

But anyway, so with the options stuff, basically we've had a long running battle with options. Much like this dog here, the options did not want to behave. So, the way Homebrew started out, a little bit of history if anyone hasn't been using it for a very long time, whatever.

Homebrew started out as being a from source package manager for Mac. The only shipped for, I think, OSX 10.5 was the version that we were at when it shipped. So, people were using it, people were building stuff from source, pretty much like the expectation was that everyone who worked on Homebrew and was submitting stuff to Homebrew were the people using Homebrew and vice versa.

So, there wasn't a long tail of users who didn't know how to modify Homebrew. It was pretty much like everyone who was using Homebrew was the ones contributing to it at the same time. And obviously, over time, the tool becomes more popular, more and more people use it, and what ends up happening eventually is we end up getting bigger,

we end up getting more support requests, and we end up getting more bugs that people find with the software. And one of the biggest causes of bugs, and you will sympathize if you run a from source like Linux distribution as well, is that weird things people have on their system, weird things they have set up in their .files or their editors or whatever,

can subtly break build processes really easily. So, we ended up having binary packages for more and more stuff, eventually binary packages for literally everything that is compiled. And then we got to a point where we noticed that effectively all our support issues are coming from a very small number of people who are doing from source builds of things,

and that made us want to use binaries more. And then the problem with the options is we have, the way it was working until recently, well, it still works this way if you're running a third-party repository, but in the main repository you would have a package and it would have, say, four or five different options in it. And because we don't have the CI infrastructure, we couldn't test that all those options actually work correctly.

And also for each option you add to a formula, you add, my math is not great, but if I've understood correctly, it's a factorial increase in the number of option combinations. Someone who knows maths is nodding at me, so I believe them. Yeah, so basically you have a dramatic number of combinations,

and some of the options didn't work, and then some of them only worked when in combination with other options. So you end up in a situation where we're shipping a bunch of software that we know is going to break, we know people are going to file issues, and we don't feel very happy about just saying, you know, like, tough, this is broken, you can't do anything about it, particularly when you end up with more and more homebrew usage being stuff like,

you know, guides on the internet saying, hey, you want to encode this YouTube video, just copy and paste this line to install homebrew, copy and paste this line to, you know, install ffmpeg with 40 different options, and then there you go. So what we've done now is we've made homebrew core have no options in it, so the binary packages are always the same for everyone, and what we're trying to do instead now is have, say something like ffmpeg,

we're trying to build it with a sensible default of things that people can use. And when people ask for something, basically we're generally adding as much as we can to provide as much support. So what we don't want to do is provide three different OpenJmpeg encoders,

but we can have a discussion about what's the best one, and then we can make that default. But, yeah, so basically this is, this may be, if you haven't bumped into this yet, this may be a couple of month hiccup, may be annoying for you, and I apologize for that, but longer term this is going to make it much easier for it to actually run the project and have it be sustainable. So, next feature. Oh, I forgot this isn't working. Right.

So this is some Counter-Strike reference. I didn't really understand that. I think it's about tapping the mouse or something, but this is some loose Google image searching this morning, so I apologize. So this reference is, anyone want to guess?

Oh, sorry, no, you started, and then I gave it away. Yes, so we now have one main tap, which is Homebrew core. Previously, a couple of years ago, we had inside the Homebrew organization

a bunch of third-party repositories, which were sort of official and sort of not. Now, the issue came about with that, that some of these taps were fairly well maintained, but would do things differently, and then some of them were completely un-maintained, like literally no one had committed to them for years at a time. And the problem is because they're all under the Homebrew umbrella, it looks like these are all official and these should all work.

So what we've done now is we've tried to move as much stuff as possible that actually works and meets our requirements into the main tap, and then we're trying to make it as easy as possible for other people to create their own taps. Sorry, I realized, who doesn't know what a tap is? Anyone? Yep, awesome. At least one person slipped their hand up. So a tap is a third-party Homebrew repository,

which effectively means if you're used to other package managers, it's just a way of having a collection of packages in one place, and what you can do is you can use the brew tap command to add more and more of these so that you can install stuff maintained by other people other than the main Homebrew maintainers.

So the default tap is on github.com slash homebrew slash homebrew core, and then any other tap is generally shortened to be, so for example, the Linux one, which I'll talk about later, would be Linux brew homebrew core, and again, that's like a short version of describing where it is on GitHub. You can also have taps that are not on GitHub or not using Git or whatever, but that's kind of a longer tale that's talked about in the man page.

Right, so the next thing, this is very niche, so this is literally, probably no one cares about this except me, so I'm not even going to ask, but Homebrew core now is all, or should be at least, all open source software. So this is something that's come up, I guess, in a few talks I've heard over this weekend,

where we're having an interesting time in open source, where we have some companies, the one that kind of jumps to mind, but they're not the only company, being like MongoDB, who are releasing open source software, which they claim to be open source software, and which other organisations, such as in MongoDB's case, I believe, Fedora, Debian, and the OSI currently claim to not be open source software.

So this puts us in a tricky situation, because we are part of software freedom conservancy, and one of the agreements of our terms as being part of that is our default repository is all open source software. So basically what we decided to do is punt the work onto someone else, which is the OSI, and we're basically saying what the OSI says is open source

is what we consider to be open source, and everything in Homebrew core should be open source under that definition. So we'll see what happens with licenses for various things in future, but it has meant we've had to do stuff like roll MongoDB back to the last version, I can't remember what it is off the top of my head, that was released under a OSI license, rather than their new SSPL thing.

But yeah, this is going to be interesting to see what happens in the next few years I think, because there's a lot of companies who are doing open source as a business type thing, who are moving in a direction which some might say is away from open source principles,

and putting additional restrictions which certainly prohibit them being considered free software anymore, and may or may not stop them being considered open source software. So we'll see what happens. Right, the next thing is this, anyone recognize this? Where you might see a page like this?

No, but that's a good suggestion. So we have a site now which is formulae.brew.sh, which is a site previously called BrowMeister, did anyone use that?

So that was like an online package browser for Homebrew, and this was sort of an import that then got a bit of a rewrite, and then it's now running on GitHub pages, basically just because I'm cheap and don't want to pay for infrastructure. But I would recommend when you look at the GitHub pages source,

you close one eye at a time, because it's doing things like rendering a JSON API, like static JSON files using liquid and things, the syntax highlighter looks like it's crying blood. So it's not happy times. But it is kind of cool how it works, and that gets updated on each push. So that also means that as well as all the information you can get about a given formula,

that's wget there, and this is all basically like JSON encoded information that we're then representing nicely. There's also a wee document on formula.brew.sh which provides an API doc, so you can now use that to query JSON information about formula

and about their analytics data as well. If you look at the very bottom, you can see installs 30 days. So this is the nice thing we've kind of got to through this as well that I'm going to talk about later. So if I talk about now. So I don't know if anyone has seen this output ever.

Again, this is relatively niche and a new command, but this is the output of brew info analytics. So that's like when we introduced Google Analytics a few years ago, one of the concerns that people had was they said it would be nice for the community to be able to access all the information the maintainers access, and we're kind of uncomfortable with there being an information imbalance.

And I can say as of the last few days, there are only two hover maintainers who have access to anything more than what the rest of the public have. And that's purely for just administrative reasons because that's how the information is generated. And the rest of it, you can get all the information on formula.brew.sh, and then you can use this brew info dash dash analytics,

which does a JSON call and pulls that data off formula.brew.sh. And basically what that's giving you is like the install counts and the balances for each of these kind of formula here. So here you can see an example of what I was talking about before of like the option removal over time. So like the options are diminishing there. So such that you get to 99.9% at the top and 99.88% at the bottom.

And again, hopefully that illustrates the point that even back when, a year ago when there was all these options, these were being used by what 0.12% of the people who were installing wget. But yeah, so this is a really nice tool both for the maintainers,

but then also if you want to kind of, I find it interesting, it's got Cask Analytics up there now as well. If you kind of almost just want to discover new software kind of based on popularity, it's kind of interesting to just kind of click through and see what stuff is there and what it's being used for, and you can kind of single click to the homepage and the formula and all this type of stuff.

Any guesses on this one? Linux support, hooray! So Homebrew and Linux, which is also known as Linuxbrew, is officially supported. Now, I don't know how many of you are Linux people in here, but there is sometimes some confusion as to why one would want to run Homebrew on a system which has, in my humble opinion,

almost always a much better package manager than Homebrew installed on it. And a common use case I've heard, or one of the best use cases I've heard, is there's quite a lot of people, I believe some of the Linuxbrew maintainers, for example, have nice Linux machines, like in high-performance computing environments, for example, which they have access to the machine, they have access to a compiler, say,

but they do not have root access on that machine. So because Homebrew itself, you can actually technically install it anywhere, we recommend you install it in the default location, because then you get all the binary packages, but because you can install it anywhere, on Linuxbrew, that means that you can basically have a fully working package manager just in your home directory, which you can use without anything

other than just a compiler, basically. So this has now been merged, the projects are still somewhat separate in that we have our formula, like the package descriptions are separate, but then the Linuxbrew brew package manager repository, the bits that are actually running the code rather than just the formula descriptions,

those repositories have now been merged, and we're kind of collaborating together as a team more than we were. Yeah, so the tap, there is a Homebrew-HomebrewCore tap, which is for all the Mac OS packages, and then there's a Linux-HomebrewCore,

which is the Linuxbrew equivalent. But you can, more and more third-party taps are providing support for both Mac and Linux, and so the stuff you could install, for example, if you installed Linuxbrew on your own machine in the home directory, you can, in theory, run any package that can be used with Homebrew. There's no underlying technical differences,

it might just be that they don't work because they need to specify more dependencies or slightly tweak the install or whatever. But again, yeah, if you were working on Mac and Linux, it's relatively easy to create your own formula that kind of can be in sync and work on both. Yes? What you mean in your home directory?

Yes. Right. Again, you can see, you can definitely probably get a theme of the ones where I spent longer on Google Image Search trying to find something that was tenuously related. So this is, basically,

Homebrew previously had things called or-later bottles, so that was a way that we allowed people to declare that a binary package, by default, the binary packages on Homebrew are just built for the Mac OS version that they're running on. So if you're on the latest version, Mojave, previously, that would have been,

you only can get binary packages that are built on Mojave because, again, Apple don't guarantee, they guarantee a reasonable amount of backwards compatibility, but certainly not forwards compatibility, so we couldn't go and just build them on one version and assume they would work. Now, after a fair bit of testing over the years and doing some tweaks to make sure this stuff works, we now do this by default,

which will probably not be noticeable or make anyone particularly happy right now, but when a new version of Mac OS is released, if you're running the betas, we generally have a bit of a frantic run to try and rebuild everything on the new version, so this won't be necessary now. We will still rebuild them for the new version to get more optimized binary packages, but you will be able to use all the binary packages

from the old versions on the newer version, which should make life a little bit nicer. So this is another one. The clue for this one is right at the bottom. Any guesses? Yeah, so we now actually verify so previously, if you passed an invalid option

to a homebrew command, you may have made out of notice. We just silently ignored it, because we just checked for did you specify this particular option string, but we now actually use a proper option parser, which validates the options for the formula, which validates the options for the command, and the nice thing with this as well is it lets us all the manually curated previously output

for all the help commands and stuff like that is now generated from the options so that we know that the documentation and the options we actually check are one-to-one in sync. So the next one, which is the last and biggest change, which you should be aware of, is that now homebrew will run brew cleanup

by default and automatically. You can opt out of this behavior, and some people may be inconvenienced by this, and I apologize, but we've had basically years and years of people on Twitter and in person being like, oh, I never knew about brew cleanup, and then I ran it, and I saved like 20 gigs of space on my machine,

and to me, others may disagree, to me that strikes me as a really bad default when people need to go and search the man page to find something that they are expected to run periodically by themselves. So now, brew cleanup is run automatically every 30 days in full, and then whenever you install or upgrade a package, it will basically clean up the old versions

behind itself as it does that. So as I say, there's an opt-out if you check the man page for that, but that's basically a new thing which will hopefully mean that it's a little bit easier for you to kind of keep your homebrew up to date. So the goal with this now is that, because I guess with 1.0 we had, brew update would be run automatically, so now you should be able to run, for example, just like brew install, brew upgrade,

and never actually need to worry about running other commands. So that is a fine workflow. Basically, if the only command you ever run are install and upgrade, then you can still use homebrew quite well now, which is hopefully getting us down to a nice minimal subset of commands that you need to know about in order to have homebrew work nicely for you. So that's the last of the features

I wanted to run through, and I have time for a couple of quick questions. Seven minutes. So, yes? Can you go to the next slide? Yeah, so homebrew cask for anyone who's not...

Oh, sorry. Repeat the question, says the thing on the bit of paper. So the question was about what is the status of homebrew cask upgrades? So homebrew cask for anyone who's not aware, that's a way of installing, basically, like binary and proprietary software, such as, say, something like Google Chrome, that you want an automated and repeatable way of installing that,

rather than going to the website and manually downloading it and click, click, click. And it allows you to use a homebrew, basically, more or less identical interface to homebrew, as part of homebrew itself now, to install that software. So the question was about upgrading brew casks and what's the status with that. Now, you can basically... I'm looking at brew cask maintenance

when I say this to make sure I'm not saying anything wrong. But my understanding is you can now upgrade brew casks, but some of them that have kind of weird versioning semantics or don't provide upstream versions, like, may behave slightly differently. Is that a fair description?

Yeah. So some casks, the latest ones, may need to have a forced upgrade, but otherwise, that's how they work now. Cool. Next question. Oh, what's next? What for homebrew? I don't know. So, yeah, yeah. So, I mean, that's one of the fun things that we're doing, which is why there's a bunch of maintainers in the room.

So we've been kind of building up our kind of funds and donations over the last few years, and we're actually spending some money now. So we have, I think, 14 homebrew maintainers who are going to be at a meeting in Brussels tomorrow, in which we're kind of going to plan some of the kind of future roadmap for the project, both on the organizational side and kind of maybe talk about some features we want to build and stuff like that.

So, yeah, basically, so from my personal viewpoint, I guess in terms of the features that I build, there's nothing really big that I feel like homebrew kind of needs now. Most of the really big things I feel like we've addressed in the last few years. So my personal priorities are more around stuff like our CI system is something that is a bit of a

bus factor of one situation, and I want to stop that being the case anymore, in case I get hit by a bus. So, yeah, like no big things on the horizon, but just trying to make things better and make the community work better.

Any other questions? Yes, good question. How do you get involved with homebrew? So, yeah, if you go to the GitHub repository, that's the best bet, and that's linked from the homepage as well. That can describe basically some easy ways to get stuck in. I would say, I mean, homebrew has 7,000 plus contributors at this point.

I would say it's probably one of the easiest projects to get involved with, certainly if you use it, because there's loads of stuff which kind of works fine, but needs slightly tweaked or cleaned up, and we have quite strict kind of linting tools. There's one called brew audit, which will go and basically like complain about various

minutiae and packages that aren't quite how we want them. So that is a really good way to get started. If you can run brew audit on packages that you already have installed and you already use, and then you have a bit of a, you know, scratch or an itch type situation going on, then you can submit a pull request to do that. Another command that's useful for that is there's a brew bump formula PR command,

which literally lets you upgrade a homebrew formula to a new version in a single commit, and then will create the pull request for you. So that's like literally the easiest way to get started with homebrew development. And then you can kind of see how that goes, and then you can get a first commit in homebrew without even having to know how to commit and create a get a pull request yourself.

So, thank you, good question. Well, I think we're question-less now. So thank you everyone for coming, and thank you for using homebrew.

Thank you.