Removes the detection logic from the Requirement in favour of it living inside
the Gpg class & us calling it from there. It's a bit nicer & avoids us calling
Requirement code from outside of direct requirement handling & fulfillment.
GPG 1.x has stopped receiving new features, some of which we may well want to
take advantage of sooner or later in Homebrew. Upstream has also been attempting
to work out for a while how well used it still is which suggests it may "go away"
at some point in the future.
Debian is also in the process of migrating GnuPG 1.x to a `gpg1` executable
whilst GnuPG 2.1.x assumes the `gpg` executable. There's a detailed video
discussion of this from DebConf 2015 at:
http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/GnuPG_in_Debian_report.webm
It's unsafe to assume every `gpg` executable is going to forever equal 1.x and
every `gpg2` executable is going to forever equal 2.x. MacGPG2 has been symlinking
2.x as a vanilla `gpg` for a while, for example, and we will be soon as well.
You'll still be able to plonk the `libexec/bin` path of `gpg` in your PATH to
access a vanilla `gpg` 1.x executable if you want to, but we're not going to
actively keep adding gpg1 support to formulae going forwards. There's really no
reason why 99.9% of projects should not or cannot use `gpg2` these days.
This uses detection methods to determine regardless of what the executable
is called we're always hitting a 2.0 GnuPG or nothing.
Substitue each Version.new and HeadVersion.new with Version.create
to unify Version and HeadVersion instantiation among core code.
Note that this does not relate to Mac::OS::Version class.
This is in part designed to handle situations described in https://github.com/Homebrew/legacy-homebrew/issues/42273
where we tell someone to install a special dependency, but because we (rightly, IMO)
resolve special dependencies first users can end up being told to execute a command
on a tool that isn't yet installed and isn't immediately obvious how to install it.
In the situation raised there, with the `sile` formula people are being told to
`luarocks install xyz` but we hadn't installed Lua for them first, so they just
get a `command not found: luarocks` message. Perhaps it should be obvious enough
how to install said tools by looking at the formula's dependencies,
but it's not a huge burden on us to make life easier than that.
Shuffled over from https://github.com/Homebrew/legacy-homebrew/pull/42576.
This test wasn't running by default, so we missed that it wasn't
actually being executed - or that it was failing when running in the
testing environment.
As far as I can tell this is not, and has not, been used either in core
or in any tap, third party or otherwise, so just remove the feature and
its test.
It made less sense to call a method `java_version` when it returns
boolean value.
ClosesHomebrew/homebrew#45501.
Signed-off-by: Xu Cheng <xucheng@me.com>
The Emacs shell sets $EMACS to "t" for detection purposes, but it causes
builds to fail when they attempt to call Emacs using the variable.
FixesHomebrew/homebrew-emacs#30.
ClosesHomebrew/homebrew#45495.
Signed-off-by: Alex Dunn <dunn.alex@gmail.com>
This reverts commit 85271644b0083cbc0fd6fea71120d1ad859fbc2a.
Alex noticed that setting PYTHONPATH causes weirdness if we depend_on
something which may be optionally built --with-python3; PYTHONPATH
unexpectedly contains python3 modules in the depending formula if
the formula upon which it depends was built --with-python3 even
though the depending formula may only use python2.
ClosesHomebrew/homebrew#43724. ClosesHomebrew/homebrew#43744.
Install it as a dependency unless already satisfied by Xcode.
require cctools_requirement
cctools_requirement should be satisfied by cctools present in opt
add build_env => false to the satify block options in CctoolsRequirement
Dependency is another similar, related class and it's super confusing
to have some Requirements that are named *Dependency.
ClosesHomebrew/homebrew#38891.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Per requirements.rb:
> XXX If the satisfy block returns a Pathname, then make sure that it
> remains available on the PATH. This makes requirements like
> satisfy { which("executable") }
> work, even under superenv where "executable" wouldn't normally be on the
> PATH.
> This is undocumented magic and it should be removed, but we need to add
> a way to declare path-based requirements that work with superenv first.
Fixeshomebrew/homebrew-python#170.
ClosesHomebrew/homebrew#38448.
