audit: ensure default dependencies don't use options.

[MikeMcQuaid]

Default option dependencies are nasty as they cause unnecessary builds from source.

[ilovezfs]

This seems likely to encourage creation of new formula options. I don't think its scope should be confined to default dependencies.

[scpeters]

Can this be optional for non-core taps? We have software that wants to use bullet with shared libraries (--with-shared) instead of static:

• https://github.com/osrf/homebrew-simulation/blob/master/gazebo8.rb#L40

I definitely take your point about causing extra compilation from source, but from our perspective, it's necessary.

[MikeMcQuaid]

I definitely take your point about causing extra compilation from source, but from our perspective, it's necessary.

Sorry, we don't believe in disabling audits like this for that. You could (should?) rework things so that that build from source isn't necessary i.e. by vendoring with a resource or adding a separate formula with the shared builds. Fundamentally Homebrew is attempting to transition from a from-source to a binary package manager and I'd recommend third-party taps seek the same.

[MikeMcQuaid]

This seems likely to encourage creation of new formula options. I don't think its scope should be confined to default dependencies.

@ilovezfs Cool. This was was easier but will make that addition.

[scpeters]

@MikeMcQuaid I hear you and respect your decisions, especially if it helps to reduce your maintenance and support workload. I haven't bothered to fork the bullet formula to change the default options, since it doesn't take very long to build. It would be different if it were something like qt. I certainly could make a bullet_shared.rb formula and build bottles for it, but then I also need to track upstream changes to bullet.rb, which is hard to automate and adds to my support workload.

[ilovezfs]

@scpeters it's not just about the time and support load. It's more so about the vulnerability of source builds to breaking at any time. If a binary install has dependencies that must build from source, it inherits that vulnerability.

For example, recently building netcdf --with-fortran spontaneously broke when Apple released Xcode 8.3 due to the addition of a new ld option named -lto_library, which CMake misinterpreted as referring to a library named libto_library.

This caused anything with depends_on "netcdf" => "with-fortran" not only to be unable to build but also to be unable to install at all even if it had a bottle.

[ilovezfs]

@scpeters regarding bullet specifically, it's likely the formula can be modified always to build and install both the static and shared libraries, and we could look at a PR for that if it's something you're interested in working on.

[scpeters]

@ilovezfs that's a good point too. I've submitted a PR to make bullet always build shared libraries, so that should help our use case: Homebrew/homebrew-core#12636

Thanks for your patience. I withdraw my objections to this PR.

[chdiza]

Fundamentally Homebrew is attempting to transition from a from-source to a binary package manager

This is very, very sad.

[MikeMcQuaid]

This is very, very sad.

If you looked at our analytics and see what percentages of users are using the default prefix and pouring bottles and also at the relative error rates on building from source vs. pouring bottles you'd be hard-pressed to justify why we should prioritise the experience of a small number of power users over the clear majority.

[scpeters]

On Mon, Apr 17, 2017 at 5:58 AM, Mike McQuaid ***@***.***> wrote: This seems likely to encourage creation of new formula options. I don't think its scope should be confined to default dependencies. @ilovezfs <https://github.com/ilovezfs> Cool. This was was easier but will make that addition. I didn't notice this distinction at the time, but I don't see the reason

to extend this check to optional dependencies, since you would have to build from source anyway to use them.

[ilovezfs]

The big reason is that otherwise these will be resolved by moving things behind options.

[scpeters]

Your argument sounds to me like "options are bad", which goes a little farther than what I thought I heard from Mike, which was about avoiding builds from source for the vast majority of users who don't specify options on the command-line.

[ilovezfs]

Fundamentally Homebrew is attempting to transition from a from-source to a binary package manager and I'd recommend third-party taps seek the same.

[scpeters]

Ok, I guess I didn't read that properly the first time, but I'm not sure exactly what it means. I think of brew cask as a binary package manager, but homebrew formulae are instructions on how to build packages from source. Do you mean that brew install will only install bottles and you'll have to use brew test-bot or some dev-cmd to build bottles from source?

Is this driven by wanting to improve the user experience for your most frequent users and to reduce the maintenance burden?

[MikeMcQuaid]

@scpeters brew cask is for distribution of upstream binaries. Homebrew is trying to distribute binaries rather than getting users to build from source whenever possible. This is because it saves time, saves upstream bandwidth and saves support requests (binaries are significantly easier to support).

We're never going to make it impossible to build formulae from source (after all, that's what we're doing ourselves) but we are going to keep ramping up brew audit such that it goes from pointing out problems to best practice for users.

[scpeters]

@MikeMcQuaid thanks for the clarification; that sounds reasonable.

[dakcarto]

@MikeMcQuaid wrote:

We're never going to make it impossible to build formulae from source (after all, that's what we're doing ourselves) but we are going to keep ramping up brew audit such that it goes from pointing out problems to best practice for users.

I think this certainly makes sense for formulae that have default dependencies with options (for the outlined reasons and bottling), but what about this scenario:

  ...
  option "with-api-docs", "Build the API documentation with Doxygen and Graphviz"
  ...
  if build.with? "api-docs"
    depends_on "graphviz" => :build
    depends_on "doxygen" => [:build, "with-graphviz"]
  end

Why would :build dependencies be required to have no options? Do I really have to vendor doxygen with graphviz support or create a new formula (for doxygen)? This seems quite restrictive for the build phase.

[ilovezfs]

To limit the vulnerability of the builds to random breakage in dependencies as already discussed above.

[dakcarto]

So, in my example above, I should separate out certain options to ancillary formulae, e.g. <formula-name>-api-doc? This would be similar to how Linux binary-only repos work.

Obviously, that works for things like docs, but I'm not so sure this won't cause more issues for intrinsic build options by forcing duplication to semi-redundant formulae (as @scpeters mentioned, before his specific problem was solved in a manner not generically applicable to all such situations).

In other words, formula authors are going to have to chose between what a given source code project considers optional (in their build configuration) and weighing that against defaulting to enabling more so that Homebrew users get the most out of their bottles. I believe this will many authors will just start turning on (or ask for) too many default build options for formula to compensate.

Just my 2-cents. Regardless, I do understand the reasoning behind this move.

[ilovezfs]

I think we're all well aware of the trade-offs here.

[MikeMcQuaid]

In other words, formula authors are going to have to chose between what a given source code project considers optional (in their build configuration) and weighing that against defaulting to enabling more so that Homebrew users get the most out of their bottles. I believe this will many authors will just start turning on (or ask for) too many default build options for formula to compensate.

This is the inherent compromise in doing package management. This audit is just providing a gentle nudge to not punt this indecisiveness (and this includes mine) onto users in a way that's more time consuming and error-prone for them.

[muellermartin]

@MikeMcQuaid regarding the analytics on the precentage of users pouring from bottles: Did you consider that power users who tend to use custom options also tend to disable analytics? This might distort your view of the usage.

[MikeMcQuaid]

@muellermartin We will not be optimising the use of Homebrew for users who disable analytics or really "power users" but instead the 99% case.

[chdiza]

We will not be optimising the use of Homebrew for users who disable analytics or really "power users" but instead the 99% case.

@muellermartin's point is it is not at all clear that they are the 99% use case.

[MikeMcQuaid]

@muellermartin @chdiza Any my point is: if people opt-out they should not be surprised when they find we do not optimise for their usage of Homebrew.

[tjanson]

I found the message

Dependency #{$1} should not use option #{$2}

confusing, since it sounded like that particular option was deprecated. (I needed to look up the source and this PR to understand the intention of the warning.) Maybe a rewording like

Dependencies should not require any options

would be clearer.