* brew install will find an aliased formula
* aliases are searched against
* warn when creating a new formula that has an existing alias.
If Subversion has an alias "svn", then warn when the user tries to
create a new formula "svn". The formula can still be created, though
the user should make sure it's not a duplicate of the existing
aliased one.
Subversion and Objective-Caml formulas get some alises here, so we have
something to test against.
These methods could be static on Formula, but splitting them out makes
it clear to formular authors that these functions don't have anything
to do with writing new formulas.
The code in Keg.self.for path uses "path = path.parent.realpath" to walk
up subfolders looking for a Keg.
Because 'realpath' is in there, and the path is checked against
HOMEBREW_CELLAR, which may be a symlink, we need to do realpath-to-realpath
comparisons in Keg. Otherwise, we will hit equivalent but symlinked folders,
not see that they are the same, and walk all the way up to / and then
error out.
If an exception is thrown while parsing the formula file before the install.rb at_exit then it will be in $!. Marshal it back to the parent brew process.
Rather than showing a backtrace that says "couldn't find command blah". Admittedly it's possible that the error will be something else, but unlikely. And this is neater.
Ideally we'd push the bt through an error pipe like we do with install.rb. And I guess we'll do this eventually.
It's a great feature but it seems to conflict with our new system() replacement. Clearly the bug is still in our system() but what exactly it is is not clear and this bug sucks.
See Homebrew/homebrew#124
As I understand it (I tested too), signal propogation is handled by the parent Ruby process. However this was working mostly anyway. So I don't fully understand what is going on. However this seems to not hang in Process.wait where it was before for one test case.
It just seems to behave strangely with SIGINT. Eg. SIGINT causes tar to exit, but the SIGINT is ignored by our process. This is not the case when used with curl.
Thus install.rb gets the path to the instantiating brew process rather than whichever is first in the PATH. Not to mention Homebrew doesn't *have* to be in the PATH.
Couldn't make this atomic, apologies.
Fixes a few things, like deps failing to build not aborting the install.
--force now works properly again.
Overall more robust code. I went back over it all and gave it a lot of
thought.
Cleaner separation of logic. Less code in brew, now the only code there is
ARGV handling, and basic sanity checks.
Not extending ARGV or ENV in global now as that would propagate to other tools
or utilities you may write.
This rewrite attempts to sort out where the Prefix, Cellar, and
Repository are relative to the real and symlinked 'brew' command.
Also included is a --config option which dumps all of these variables.
Any top-level script must define a "BREW_FILE" that gives the path
to brew as it exists in the path. 'brew' itself just uses __FILE__ and
install.rb does a `which brew` (there may be a better way?)
The Prefix is always relative to the location of brew as it exists in
the path. Thus, whether or not /usr/local/bin/brew is a symlink or real
file, the Prefix is always /usr/local. If you have brew in some other
prefix, such as /nonstandard/bin/brew, then '/nonstandard/ will be
managed by brew instead.
The Repository, Cellar, and "Library/Homebrew" required code is always
found relative to the "real" path or brew. If brew is a real file in
/usr/local/bin/brew, then everything else will be found in /usr/local
and we'll expect a /usr/local/.git
Otherwise, we dereference brew's symlink and look for everything else
relative to that path instead.
Using an error pipe.
The use of ENV[HOMEBREW_ERROR_PIPE] feels wrong, but I wasn't sure how else to
proxy the file descriptor to the child process since the fork immediately
calls exec.
I found yet another instance where the escaping wasn't perfect, so got fed up and just did it in Ruby. I hope this works for all existing usage. It should.
The bonus here is that you can use RegExps now.
