Doesn't feel like a good reason to abort installation for users if the
formula author has specified a conflict that doesn't exist. Instead,
behave more like the `TapFormulaUnavailableError` but print a message
telling people to report to the formula authors.
Closes https://github.com/Homebrew/homebrew-versions/issues/1327
Introduce `--fetch-HEAD` option. Without this option upgrade and
outdated never fetch latest upstream commit to detect if HEAD is
outdated -- tabs are used instead. However, if option is passed,
we fetch commit from upstream, which is more time consuming,
but we can be sure that version is up-to-date or outdated.
* add `latest_head_version` to return latest HEAD version installed
* add `latest_head_prefix` to return Pathname with latest HEAD version
* add `head_version_outdated?` to check if HEAD version is up-to-date
If we try to call `Formulary.from_keg(f, :head)` on the keg that
is not HEAD-keg itself, we don't need to update commit of
returned formula and should use just HEAD version with nil commit.
Same is true for `ARGV.resolved_formulae`
This basically started once our integration tests caused the overall
test time to raise above 10 minutes, causing some coverage data to be
dropped because SimpleCov believed it to be stale.
When running on Travis CI, both the Linux and macOS build will send a
coverage report, causing them to be merged by Coveralls. This results
in inferior coverage due to the early stage of the Linux-specific tests
and is probably not what we want. Make sure we only send a report for
macOS (assuming we stick with a single macOS build in `.travis.yml`).
No longer output every cask under the list of changed formulae but
instead create a dedicated, unprinted report section for casks and then
iterate through that instead.
`any?` is not the opposite of `empty?`. Besides the case that
`[false, nil].any?` will return false, `any?`(O(n)) has much worse
performance than `empty?`(O(1)).
* python: tweak script linking in virtualenv
Instead of making the formula author use a slightly awkward block like
venv.link_scripts(bin) { venv.pip_install buildpath }
avoid exposing this implementation detail and offer the more familiar:
venv.pip_install buildpath, :link_scripts => bin
* Add non-block form and use instead of recursion
* Update 'pip_install' documentation
* Remove obsolete 'link_scripts'
* Add test for 'pip_install' with linking scripts
Also drop no longer relevant (and broken) `link_scripts` test, that
served as a template for the new test.
* Restore compatibility with Ruby 1.8.7
* Replace option hash with 'pip_install_and_link'
* Avoid confusing 'Object#tap' and fix silly bug
* Avoid side effects in mock object parameter check
* Simplify argument check (no need for a block)
Rather than nudge people to run `--strict` and then ignore some of the
results sometimes (e.g. GitHub repository notability) instead add a
dedicated `--new-formula` option that implies this is a one-time
advisory check.
There's an old bug in `file` which means it can't read certain files under a
non-C locale. This has been fixed upstream for some time, but Apple hasn't
picked that fix up & even on OS X El Capitan the `file` is ancient.
This is currently causing a lot of false positives in our bottle code around
relocating things like manpages translated into non-English languages, because
currently the test does:
```
pn = "/usr/local/Cellar/vim/7.4.2109/share/man/fr/man1/vim.1"
Utils.popen_read("/usr/bin/file", "--brief", pn).include?("text")
```
Which returns `false`. But it isn't returning `false` because the actual result
is false, but because `file` panics & fails, which for us equals a `false`. The
actual output when accessed is:
```
pn = "/usr/local/Cellar/vim/7.4.2109/share/man/fr/man1/vim.1"
Utils.popen_read("/usr/bin/file", "--brief", pn)
"ERROR: line 22: regexec error 17, (illegal byte sequence)\n"
```
Forcing this check to be done under a "C" locale eliminates this particular false
positive for strings we can't relocate & consequently things such as NLS may
prove to be more portable in some formulae than is currently the case.
Using `vim` again for the example:
```
pn = "/usr/local/Cellar/vim/7.4.2109/share/man/fr/man1/vim.1"
Utils.popen_read("/usr/bin/file", "--brief", pn).include?("text")
true
```
This reduces the flagged strings from `vim` from 4 issues to 2, the remaining
two with the `vim` executable itself which "remembers" the full path to perl,
python, ruby, etc during build & vomits that information out when requested
by the user. Both the manpages flagged before this change are no longer flagged
as unrelocatable.
This won't entirely resolve the NLS problem because some things hardcode in
a locale path, which will be stored in the executable, but at the very least it
should reduce the number of false positives & may enable relocation where that
locale path hasn't been burnt in.
