- Use the `Formula.cache` and `Cacheable` rather than rolling our own.
- Use keyword arguments instead of `options = {}`
- Improve readability in general
- This also required auto-fixes for Layout/EmptyLinesAroundBlockBody and
Layout/InconsistentIndentation once the auto-fixer had got rid of the
"redundant begin"s.
This API is used internally correctly and externally mostly correctly
but #6230 reveals the external usage is fairly confusing and a bit
unsafe by default. Preserve the existing API while verifying the
checksum by default and providing an opt-out. Using the existing, safe
method will result in a double verification of the checksum which is
harmless. A Homebrew/homebrew-core PR will follow shortly to address
those cases.
Fixes#6230
This is a replacement for the rubydoc.info site that has been a bit
unreliable for us.
Also, note we're using the community Ruby style guide now rather than
the GitHub one.
Adjust the rules based on the current codebase. Remove various enable,
disables and default values that are unnecessary. Add more comments
explaining why. Make minor changes needed to enable a few more rules.
Use 124 max line length everywhere. Also, reduce tap max line length to
189 as Homebrew/homebrew-core has that as a maximum now. In future
Homebrew/homebrew-core will also be reduced to 124 maximum line length.
I hadn't planned to move on this so quickly but impressively core
today had its first Go Module using PR, so this has become more useful
than it would've been. Useful reading on the Modules system can be found
via https://golang.org/doc/go1.11#modules.
`GOCACHE` has been a thing for a while but it hasn't really been
especially beneficial to us, so I've ignored it, but with the Go Modules
system it can be incredibly useful in reducing build times & thus CI
burden. A lot of this is explained rather nicely here:
https://groups.google.com/forum/#!msg/golang-dev/RjSj4bGSmsw/KMHhU8fmAwAJ
The upsides here for us are obvious:
1) We do a *lot* of go-based builds, and the more things move over to the
module system the more comprehensive that cache will become and we'll
need to remotely fetch less dependencies, which massively speeds up
build times even on high-speed connections.
2) Module dependencies aren't limited per formula. If `hugo` fetches a
dependency that is the same version as, for example, `wiki` also needs
`wiki` won't bother to fetch that version remotely but instead will
simply pluck it out of the cache.
If we look at `hugo`, because it's the only formula so far with Module
support:
First build: `built in 1 minute 41 seconds`
Second build: `built in 14 seconds`.
It's worth noting perhaps that we can use just the module cache rather
than the build cache + module cache combination, but doing so leads to
a significant reduction in regained build time. A build under that
system pops an average build time with `hugo` (after the first build)
of ~70 seconds, which is only a 30 second saving on the first build.
However, if we wanted to speed up builds whilst also not eating big chunks
of disk space that is an option.
The downside of a build cache + module cache system is disk usage.
`go` does not exactly eat up disk space sparingly, and the cache size
from `hugo` alone is 258.8MB. That could be an issue on CIs where disk
space is already a squeeze at times, but it's not much different to how
we let the `java_cache` behave now.
All Module-supporting formulae need to do to use the shared cache is
instead of deleting the `GOPATH` env we set everywhere replace it with
this:
```
ENV["GOPATH"] = "#{HOMEBREW_CACHE}/go_cache"
```
Hopefully put this to bed for once and for all. Add a new method
`runtime_formulae_dependencies` which returns the `runtime_dependencies`
which have only the `Formula` objects that exist. I've checked all the
`runtime_dependencies` callers and updated them accordingly.
Also, fix a few cases where runtime dependencies were being read from
the tab when this wasn't desirable.
