Not every Linux system has a pre-installed `uuidgen` command (Debian
has a package `uuid-runtime` but doesn't install it by default). In
contrast, `/proc/sys/kernel/random/uuid` is always available on a modern
Linux system and produces type/version 4 UUIDs, just like `uuidgen`.
Closes#416.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
Since #292, HOMEBREW_CACHE was moved to a per-user directory. This makes
it unsuitable to store global lock files on multiple users environment.
Therefore, introducing a global lock directory `/Library/Lock.d` to
store lock files from formula lockers as well as `brew update`.
* Move GitHub API module to utils/github.rb.
* Move curl method to utils/curl.rb.
* global: use long curl arguments and an array.
This makes the code more self-documenting.
* utils/curl: support reading curl's output.
* utils/github: use curl instead of open-uri.
It has far better proxy support.
* pull: set Homebrew user agent.
* gist-logs: remove trailing whitespace.
* gist-logs: use first instead of [0].
Easier to read.
* gist-logs: use curl-based GitHub.open method.
Prior to this change there were only 3 instances of `STD(IN|OUT|ERR)`
versus 74 instances of `$std(in|out|err)` in the Homebrew code base. The
latter variant is also strongly suggested by bbatsov's Ruby Style Guide.
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.
Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.
See more detailed discussions in #145.
Closes#162.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
This prevents `brew` self-calls from interacting with the stickiness of
HOMEBREW_NO_ANALYTICS being persisted to the brew repo and accidentally
disabling analytics permanently when it should have been for just one run,
while restoring the stickiness of an explicit user-supplied
HOMEBREW_NO_ANALYTICS.
DO not invoke git config because HOMEBREW_NO_ANALYTICS, otherwise
it will disable analytics for everyone when running `brew update`
in following manners:
* `brew update` will set HOMEBREW_NO_ANALYTICS because the absence of
`homebrew.analyticsmessage`
* `brew update-report` will set `homebrew.analyticsdisabled` because of
HOMEBREW_NO_ANALYTICS.
Also reduce file IO.
Provide a single command that can be run to disable analytics, run it if
`HOMEBREW_NO_ANALYTICS` is ever set and remove the user UUID file in
that case too.
References https://github.com/Homebrew/brew/issues/142.
This collects all violations for each formula in a single place, instead
of doing `brew style` outputs for all formulae first, and then the other
audit checks.
Closes#112.
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
Two methods:
* `Utils.git_available?` checks whether git is installed.
* `Utils.ensure_git_installed!` installs git for users who don't install
Xcode or CLT.