brew upgrade php54-augmentedtypes fails on missing phpdoc

[silvamerica]

It looks like attempting to install php54 (a dependency for php54-augmentedtypes) breaks on a missing phpdoc.

mbp:~ $ brew upgrade php54-augmentedtypes
==> Upgrading 1 outdated package, with result:
php54-augmentedtypes 0.6.2
==> Upgrading php54-augmentedtypes
==> Installing php54-augmentedtypes dependency: php54
==> Downloading http://www.php.net/get/php-5.4.30.tar.bz2/from/this/mirror
Warning: Backing up all known pear.conf and .pearrc files
Warning: If you have a pre-existing pear install outside
         of homebrew-php, or you are using a non-standard
         pear.conf location, installation may fail.
==> ./configure --prefix=/usr/local/Cellar/php54/5.4.30 --localstatedir=/usr/local/var --sysconfdir=/usr/local/etc/php/5.4 --with-config-file-path=/usr/local/e
==> make
==> make install
==> /usr/local/Cellar/php54/5.4.30/bin/pear config-set php_ini /usr/local/etc/php/5.4/php.ini
 in Unknown on line 0

Fatal error: Function annotation compilation failed for function usage in file /usr/local/Cellar/php54/5.4.30/lib/php/pearcmd.php at line 318, error message: No phpdoc specified - all named functions require phpdoc. (Did you remember to use /** ?)
 in Unknown on line 0


READ THIS: https://github.com/Homebrew/homebrew/wiki/troubleshooting
Error: undefined local variable or method `f' for #<BuildError:0x007f9e22837378>
Please report this bug:
    https://github.com/Homebrew/homebrew/wiki/troubleshooting
/usr/local/Library/Homebrew/exceptions.rb:182:in `dump'
/usr/local/Library/Homebrew/cmd/upgrade.rb:84:in `rescue in upgrade_formula'
/usr/local/Library/Homebrew/cmd/upgrade.rb:92:in `upgrade_formula'
/usr/local/Library/Homebrew/cmd/upgrade.rb:43:in `block in upgrade'
/usr/local/Library/Homebrew/cmd/upgrade.rb:43:in `each'
/usr/local/Library/Homebrew/cmd/upgrade.rb:43:in `upgrade'
/usr/local/Library/brew.rb:131:in `<main>'

[jmarrama]

Oh boy. This is an unfortunate artifact of the default configuration for php54-augmentedtypes instructing augmented types to enforce everything by default. This can be worked around by commenting out the last line of /usr/local/etc/php/5.4/conf.d/ext-augmented_types.ini by putting in a leading semi-colon.

[silvamerica]

Is it possible to exclude it for building php and other php extensions?
Otherwise you always have to do this for each time you run brew upgrade.

Nicholas Silva
Senior Software Engineer, Box
[email protected]
510-847-4977

On Tue, Jul 8, 2014 at 11:26 AM, Joseph Marrama [email protected]
wrote:

Oh boy. This is an unfortunate artifact of the default configuration for
php54-augmentedtypes instructing augmented types to enforce everything by
default. This can be worked around by commenting out the last line of
/usr/local/etc/php/5.4/conf.d/ext-augmented_types.ini by putting in a
leading semi-colon.

—
Reply to this email directly or view it on GitHub
#14 (comment).

[jmarrama]

I'd like to include an option in the brew recipe for augmented types to not include that particular ini setting. You can't selectively exclude projects from AT enforcement without either modifying php code or changing that ini setting.

[anthonybishopric]

You should submit a PR to https://github.com/Homebrew/homebrew-php/blob/master/Formula/php54-augmentedtypes.rb to write a config file that excludes /usr/local/Cellar/php5x instead of the default ini settings. Otherwise, AT seems to be doing what it should.

[jmarrama]

That would be a good solution, but the blacklisting/whitelisting functionality is only available in php, not ini directives. IMO, the better solution would be just to make it a configurable option to not set the enforce_by_default directive upon install. I don't think that adding in white/blacklisting to ini settings is a particularly elegant solution. Plus, what if someone developing in /usr/local/Cellar/php5x wanted to use AT? :)

[anthonybishopric]

Someone developing in their homebrew vendor directory is not someone I trust.

Also, if you enable enforce_by_default then you're right back to square one on this problem.

[ghost]

It feels like the core of the problem is putting the white and black list in PHP code itself. I'm all for circularity but it seems like you will run into persistent problems like this if any code gets run before the black and whitelist can be processed. enforce_by_default seems like the wrong lever to be using to deal with those issues.

The right solution seems to be putting the black and whitelist in the ini itself.

[jmarrama]

@JHuffaker - you hit a recent problem right on the head. Nasty stuff happens when files are ran before the whitelist and blacklist can be processed. I just added functionality to add paths to the white/blacklist via two ini directives 'whitelist' and 'blacklist' in commit eed4bdf