Expedite Forward Progress

[RandomDSdevel]

     Homebrew/brew#5477's deprecation of brew's 'HOMEBREW_BUILD_FROM_SOURCE' environment variable and Homebrew/homebrew-core#31510's excessive removal of options from package build formulas makes offering individuals who've used Homebrew as a from-source package manager since time immemorial increasingly paramount sooner rather than later. Those PRs were the straws that finally broke the camel's back, so to speak.

CC @chdiza, @zbeekman, @DomT4, @blogabe, @danieljl, and @rw due to their potential interest here.

[RandomDSdevel]

     @rw has at least one initial thought in #6.

[RandomDSdevel]

     I've started creating issues in our 'brew' fork. Add to these as you think of areas to cover.

[RandomDSdevel]

     Note that I'm foregoing the usual formalities (with respect to filling out templates) to make filing some of these initial issues more streamlined, but I can always go back and edit those culprits to fix that later and don't mean to do so for long.

[RandomDSdevel]

     I've now opened portage-brew/brew#5 to revert Homebrew/brew#5477's deprecation of brew's 'HOMEBREW_BUILD_FROM_SOURCE' environment variable, but I'm holding off on merging it until we resolve portage-brew/brew#2.

[RandomDSdevel]

     We'll need to partially revert Homebrew/brew#5598 once it lands, so I'm noting that here for picking up on later.

[RandomDSdevel]

@blogabe with respect to your comment on #8:

A recent change homebrew introduced is that even if you build a formula from source, the relevant dependencies will still be bottles. …

     I remember seeing that change, but can't find it at the moment. How recent was it again? On that note, did I miss something in portage-brew/brew#5?

…This is a problem in my opinion if the whole point of this project is to continue building from source and offering options.

⋮

     I agree!

⋮

The way around this is to brew deps -n --include-build --include-requirements <formula> <options> and install those dependencies from source. For example:

brew install --build-from-source `brew deps -n --include-build --include-requirements blogabe/xplanet/xplanetfx --with-gnu-sed --with-gui | grep -v ':macOS'` && brew install --build-from-source blogabe/xplanet/xplanetfx --with-gnu-sed --with-gui

⋮

     Yeah, that's ugly; we shouldn't have to do anything like that.

⋮

There was another recent change today, Homebrew/brew@7b6d1f7, that breaks the above workaround and ignores the formula's options. Speaking with Mike about resolving the issue so that we can still build dependencies from source. As of right now, however, all dependencies are back to being bottles.

     Thanks, I'll follow along upstream.

[blogabe]

I'm unsure which change was the one that forced dependencies to be poured as bottles even if the --build-from-source flag was set. Lot of changes lately. I was messing around to see how these changes impact the installation procedures for some formulae I care about and noticed it.

It's totally an academic exercise at this point just to see if I can get everything built from source. graphite2 seems to be an exception... can't be built from source and only available as a bottle (based on cursory look).

Today's change was to /Library/Homebrew/cmd/deps.rb that no longer allows formulas with options to display the dependencies the options require.

[RandomDSdevel]

@blogabe:

I'm unsure which change was the one that forced dependencies to be poured as bottles even if the --build-from-source flag was set. …

     OK, guess we'll have to dig for it some more.

…Lot of changes lately. …

⋮ (Snipped…)

     Yeah…

⋮ (Snipped…)

Today's change was to /Library/Homebrew/cmd/deps.rb that no longer allows formulas with options to display the dependencies the options require.

     Yes, I remember the PR being Homebrew/brew#5587.

[DomT4]

CC /snip/ @DomT4 /snip/ due to their potential interest here.

FWIW, I think Homebrew deserves to be forked, and I'm aware of at least one private effort that had made decent progress on this front (which I won't disclose; that's for them to do), but I'm unlikely to get especially involved myself at the moment beyond being willing to offer advice where needed.

I keep a copy of Homebrew active locally to keep my three personal taps going, but beyond those three taps I've basically moved on.

[RandomDSdevel]

@DomT4:

⋮

FWIW, I think Homebrew deserves to be forked, and I'm aware of at least one private effort that had made decent progress on this front (which I won't disclose; that's for them to do), …

     Interesting to know. I'll keep an eye out and see if they become public; maybe we can join forces, then.

…but I'm unlikely to get especially involved myself at the moment beyond being willing to offer advice where needed.

I keep a copy of Homebrew active locally to keep my three personal taps going, but beyond those three taps I've basically moved on.

     Cool, fair enough.

[chdiza]

@DomT4 might be talking about me. I made a fork in October to hack on, and it's been working great.

I doubt we should join forces, though. That's because the goals of my fork seem to be drastically different from the goals of portage-brew. I forked HB for two reasons: (1) to reverse some ludicrous decisions that HB enacted; (2) to strip out all the utter bullshit and unnecessary stuff (which it turns out is like 85% of HB!) and yield a system that simply makes it easier for a user to build from source (no bottle support at all) and lightly "manage" things that are already installed. I.e., it will basically just run a build through superenv, and let you switch and link/unlink and ls and uninstall and stuff.

While I can tell that (1) is also a goal of portage-brew, I think that my fork is far, far too minimal to be what you want. (E.g., reinstall has been deleted, but it's one of the first goals mentioned in the portage-brew README.) There won't even be a core or required tap.

(FYI: part of the reason for the quest for minimality is to make maintenance easier. I've already got the 9MB Library/Homebrew folder down to 3MB. That's 6MB that nobody would ever have to look at again.)

[blogabe]

All I really want is to be able to build from source and have compile time options available. Outside that, everything else is gravy. With respect to the how, I'm afraid I'm not nearly enough of a coder to suggest a deep dive solution. Conceptually, I like the idea of a tap feeding into HB to make it easier to work with them. But I get if that's unfeasible and an independent project needs to materialize to make this happen.

[RandomDSdevel]

@chdiza, @blogabe:

@DomT4 might be talking about me. I made a fork in October to hack on, and it's been working great.

⋮

     Great to hear!

⋮

I doubt we should join forces, though. That's because the goals of my fork seem to be drastically different from the goals of portage-brew. I forked HB for two reasons: (1) to reverse some ludicrous decisions that HB enacted; (2) to strip out all the utter bullshit and unnecessary stuff (which it turns out is like 85% of HB!) and yield a system that simply makes it easier for a user to build from source (no bottle support at all) and lightly "manage" things that are already installed. I.e., it will basically just run a build through superenv, and let you switch and link/unlink and ls and uninstall and stuff.

While I can tell that (1) is also a goal of portage-brew, I think that my fork is far, far too minimal to be what you want. (E.g., reinstall has been deleted, but it's one of the first goals mentioned in the portage-brew README.) …

     Besides what you've done with 'reinstall,' that actually sounds a lot like what we're looking for (or at least I am.) Starting with something overly minimal would put us a lot farther along than where we'd be if we were to continue working off of Homebrew upstream as it stands now. Even something to draw parallels from would be appreciated, though. What's currently in the read-me is really only my thoughts right now, anyway, and I mean to move them into a separate document and put something else there.

…There won't even be a core or required tap.

⋮

     I'm with @saagarjha that not having a central tap would be grounds and cause for unwanted fragmentation, but I can appreciate the appeal of not having any tap be special. Regardless, an organization fork of Homebrew/homebrew-core is pending.

⋮

(FYI: part of the reason for the quest for minimality is to make maintenance easier. I've already got the 9MB Library/Homebrew folder down to 3MB. That's 6MB that nobody would ever have to look at again.)

     Impressive!

[blogabe]

Thanks for pulling this all together @RandomDSdevel and organizing. Wherever this or other projects that have been created in response to HBs changes go... will be fun to get back to something more closely resembling HBs original concept.

[RandomDSdevel]

@blogabe:

Thanks for pulling this all together @RandomDSdevel and organizing. …

     Well, I don't know if I could call us 'organized' enough just yet, as such, but, thanks, I appreciate it.

[chdiza]

BTW @RandomDSdevel, I don't know if you're aware of this or not, but all of your comments, when github automatically emails them out, are loaded with many repetitions of  . It makes them super difficult to read. It's like this when you comment on the HB repo too. And yours are the only ones that result in this. Are you posting comments by sending HTML email to github or something? Or are you using the web interface but deliberately beginning paragraphs by keying in non-breaking spaces?

[chdiza]

E.g., here's what a line of your most recent comment looks like in email:

     Well, I don't know if I could call us 'organized' enough yet, as such, but, thanks, I appreciate it.

[RandomDSdevel]

@chdiza: Errr…I begin nearly all my paragraphs pretty much everywhere with forced hanging indents. If I enter plain spaces, GitHub eats them.

[saagarjha]

FWIW, I'm not seeing HTML entities in Mail.app.