e70a3552d3 seems to have
exacerbated the problem where taps stick around and then `brew uses` gets executed
on a whole host of taps, which is currently breaking almost every PR for formulae
that would be used cross-tap, as well as causing lengthier CI builds.
Examples from the last week or so include sqlite, V8, protobuf, and so on. Whilst it
may be true that cross-tap formulae failing can show problems that need looking at,
a lot of the time the failures are unrelated to the build in question and just
leave contributors confused on what needs to be done, or why their PR is failing
for something that seems entirely unrelated.
You can see the taps failing to vanish locally by doing something like:
```
brew tap homebrew/fuse
brew tap homebrew/versions
cd $(brew --prefix) && git clean -ffdx --exclude=/Library/Taps/
brew tap
...
homebrew/core
homebrew/fuse
homebrew/versions
```
This is a very simple proposal to handle the problem, but there's no real reason
I couldn't write this functionality into untap itself and then we call that in
test-bot. Just didn't necessarily want to jump immediately to expanding the untap
command to solve what is more-or-less a CI problem.
Also enables sandbox for --interactive and --debug use of install
and test, using automatic retention.
Closes#66.
Signed-off-by: Andrew Janke <andrew@apjanke.net>
Showing help makes sense for `brew help <command>`, but showing it for
`brew <command> help` is undesirable and prevents all commands from
accepting a named argument `help` (formula, tap, file name, etc.).
All other help flags are still detected before *and* after the command.
Closes#103.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
Keep the footprint of `brew.rb` small. Handle fetching/displaying an
appropriate help text (taking into account various external conditions)
in the `help` command.
Don't search for alternatives if formula was found, but has issues, as
this will create confusing output, particularly for contributors working
on a formula file.
Changes to the man page are made in `header.1.md`, `footer.1.md`, or the
documentation comment block in the respective command file. Remove old
Markdown file to reduce confusion, now that it is no longer needed (and
not even used by `brew man`).
Since edf000e4cd30c3626ccc28c52ed32f2d84a200dd `zsh` completions are in
`share/zsh/site-functions/_brew`, making this path a part of Homebrew.
Hide it from `brew list --unbrewed` to reduce confusion/noise.
Currently, brew audit --strict includes the name of the tap when calculating the
length of a formula's description. This makes it difficult to pass the audit for
formulas in taps with lengthy names. In #47033 @jawshooah called out head-only
or devel-only taps specifically, but this is an issue elsewhere. For example:
homebrew/versions/elasticsearch20: Distributed search & analytics engine (72)
This commit updates audit.rb to use formula.name rather than formula.full_name.
Closes#47033 -- Audit shouldn't include tap name in description length
By the commit edf000e4cd30c3626ccc28c52ed32f2d84a200dd, bash and zsh
completion scripts have been moved to `etc/bash_completion.d/brew` and
`share/zsh/site-functions/_brew`, respectively. Now completion will be
done automatically without any trick.
Old logic doesn't include revision. This fixes that, and passes the
whole formula prefix path to avoid duplicating the path-construction
logic.
Closes#80.
Signed-off-by: Andrew Janke <andrew@apjanke.net>
- add `HOMEBREW_PRODUCT` global variable
- only differentiate between `/usr/local` and `non-/usr/local` Homebrew
prefixes to avoid sharing sensitive user information
- note if e.g. build errors are occurring under CI
- Add `HOMEBREW_NO_ANALYTICS` variable (this will be how people opt-out
when this is enabled for everyone)
- Add `HOMEBREW_ANALYTICS_DEBUG` variable to output all the analytics
that are sent
- Move Bash analytics code to `Library/Homebrew/utils/analytics.sh`
- Add documentation for our analytics and why/what/when/how and opt-out
- Only official Homebrew commands are reported
- Ruby analytics are now reported in a forked, background process
Use both an in-class and a `.git/config` cache for this so we can ensure
that the `Tap#private?` check is fast. Also, make sure this cache value
is set both when initially installing and updating a tap.
Thanks to @xu-cheng for most of the implementation here.
Also, slightly tweak the behavior of `brew update` in this case so that
it doesn't print annoying output and still allows the `brew edit` flow
for people with `HOMEBREW_DEVELOPER` set.
Don't exit with a non-zero status code just because an internal command
happens to be undocumented. Also print the generic help in these cases
to provide some help (including a reference to the man page).
This is also used by `brew <cmd> --help`. The basic idea is to have the
documentation as a top level comment in each command file. To find these
comments, they have to be like this `#:`.
This is also used by the `brew man` command to keep the documentation
DRY, and for that there are now a header and footer for the man page.
Fix style of previously omitted `check_for_bad_install_name_tool`
method to be in line with changes made in #49.
Closes#56.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
Guard clauses instead of if/unless blocks make the checks easier to
understand and reduce nesting, thus improving overall readability.
This includes the following additional minor changes:
- Make indentation of commands consistent inside diagnostic messages.
- Fix minor typos and inconsistent punctuation in diagnostic messages.
- Fix here documents to always start with `<<-EOS.undent` on a new line,
followed by the message (indented once), followed by `EOS` (at the
same level like `<<-EOS.undent`).
- Always separate the check logic (and guard clauses) from the following
message by a single empty line (for consistency and readability).
- Standardize on `message` as the variable name when diagnostic messages
need to be constructed from multiple parts.
- Where easily possible, adapt check logic to stay within 80-column
limit, use more expressive variable names, and break down long
expressions into multiple statements with intermediate results.
Closes#49.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
Using `git` from `Formula#install` can cause an exec bomb if used in a
formula with `env :userpaths` because that causes both `Library/ENV/4.3`
and `Library/ENV/scm` to be in PATH, both of which contain a `git`
binary that is the same SCM wrapper. Those will mutually exec each other
indefinitely as they fail to detect that they are the same wrapper.
Extend the exec-bomb protection to check the paths after all symbolic
links have been expanded to prevent this situation.
Fixes#43.
FixesHomebrew/homebrew-core#133.
FixedHomebrew/homebrew-core#143.
Closes#46.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
