search

Homebrew / brew

🍺 The missing package manager for macOS (or Linux)
https://brew.sh
BSD 2-Clause "Simplified" License
40.77k stars 9.57k forks source link

Consider creating a homebrew/xcode tap #1075

Closed ilovezfs closed 7 years ago

ilovezfs commented 7 years ago

Just as we've done for X11 and TeX, it may make sense to put formulae that have a hard Xcode.app dependency in their own tap.

Of the 3,604 formulae in core, there are 49 with a depends_on xcode:

All of the above call xcodebuild except these 20

which may in particular be candidates for being tweaked to no longer need Xcode.

Some of the formulae that do call xcodebuild may to a lesser extent also be candidates for such tweaking.

ilovezfs commented 7 years ago

Reverse dependencies that would be affected, assuming that the Xcode requirement cannot be eliminated for their dependency, are

graphvis:

phantomjs:

unar:

qt5:

plus any qt reverse dependencies as they are transitioned to qt5:

MikeMcQuaid commented 7 years ago

Another thing that may help some of these: depending on our swift formula rather than Xcode for some swift stuff.

ilovezfs commented 7 years ago

Would a :swift requirement make sense, able to be satisfied by Xcode.app or our swift formula?

MikeMcQuaid commented 7 years ago

@ilovezfs Yep 👍

MikeMcQuaid commented 7 years ago

Although, I'm an idiot because actually Swift is provided by the CLT...

ilovezfs commented 7 years ago

I'm an idiot

Well, now we know that's not true.

because actually Swift is provided by the CLT...

maybe it wasn't originally? somehow that memory got there! hehe

DomT4 commented 7 years ago

Gotta be honest, I'm pretty 😢 about the prospect of moving anything more to a tap that isn't the boneyard. At this point I'm prepared to call the vast majority of Homebrew organisation non-core taps a failed project, especially around getting communities interested in maintaining them & keeping them up-to-date that way.

Taps are vastly unloved & I think we're genuinely better boneyarding things we no longer want to maintain than chucking them in a tap with a vague promise that maybe it won't be more-or-less abandoned fairly imminently.

chdiza commented 7 years ago

it may make sense to put formulae that have a hard Xcode.app dependency in their own tap.

I'm curious as to what would be gained by doing this.

As to what would be lost by doing this, I can think of at least two things: the more times the user has to tap something, the more annoying it is for the user. And the more times the user has to type "sometapname/someformulaname" rather than "someformulaname", the more annoying it is for the user. There should be some kind of significant gain to offset this.

(This wouldn't affect me personally, since everything on that list that I use I've either already made my own custom local formula for, or don't use HB to manage.)

ilovezfs commented 7 years ago

Yup, the CLT alone is insufficient to prop up what rightfully belongs in core.

MikeMcQuaid commented 7 years ago

Gotta be honest, I'm pretty 😢 about the prospect of moving anything more to a tap that isn't the boneyard. At this point I'm prepared to call the vast majority of Homebrew organisation non-core taps a failed project, especially around getting communities interested in maintaining them & keeping them up-to-date that way.

Taps are vastly unloved & I think we're genuinely better boneyarding things we no longer want to maintain than chucking them in a tap with a vague promise that maybe it won't be more-or-less abandoned fairly imminently.

That's pretty fair. Unless it's a single maintainers pet project (e.g. @dunn and homebrew/emacs) or an existing community tap we've brought in (e.g. homebrew/php, homebrew/science) the taps that are basically "not good enough for core but we feel bad saying no" are fairly dismal and we should consider shutting them down and moving stuff into core or the boneyard.