Hey guys,
I'm the maintainer of the phpunit[1] package and I've talked about my idea with Dylan Ferris, maintainer of the php-composer[2] package.
The idea is that we should find a standard place for PHAR's which are installed by pacman instead of PEAR. Of course it's obvious that we should omit the ".phar" part and put it in /usr/bin, but there are two problems with it. First, if open_basedir is used in php.ini, it has to contain /usr/bin. The other problem is that IDE's won't see them that way and cannot be used as external libraries (which is mostly fine with composer, but absolutely not with phpunit).
So to solve this problem, I suggest to put these packages to /usr/share/webapps/phar or /usr/share/php with the .phar extension so the IDE's could use them and symlink them to /usr/bin without the extension so they could be invoked from command line as any other program.
The default open_basedir in the php package is "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/", so the former path would be more convenient, but the latter would be more elegant in my opinion, as PEAR packages are in /usr/share/pear/. Of course it would be nice to include that path in the default open_basedir.
What do you think?
Regards, Attila Bukor
[1]: https://aur.archlinux.org/packages/phpunit/ [2]: https://aur.archlinux.org/packages/php-composer/
Hey guys,
In case anyone is interested, since we've received no answer, we've decided with /usr/share/webapps/bin/
Cheers, Attila
On 02/28/2014 02:35 PM, Attila Bukor wrote:
Hey guys,
I'm the maintainer of the phpunit[1] package and I've talked about my idea with Dylan Ferris, maintainer of the php-composer[2] package.
The idea is that we should find a standard place for PHAR's which are installed by pacman instead of PEAR. Of course it's obvious that we should omit the ".phar" part and put it in /usr/bin, but there are two problems with it. First, if open_basedir is used in php.ini, it has to contain /usr/bin. The other problem is that IDE's won't see them that way and cannot be used as external libraries (which is mostly fine with composer, but absolutely not with phpunit).
So to solve this problem, I suggest to put these packages to /usr/share/webapps/phar or /usr/share/php with the .phar extension so the IDE's could use them and symlink them to /usr/bin without the extension so they could be invoked from command line as any other program.
The default open_basedir in the php package is "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/", so the former path would be more convenient, but the latter would be more elegant in my opinion, as PEAR packages are in /usr/share/pear/. Of course it would be nice to include that path in the default open_basedir.
What do you think?
Regards, Attila Bukor
On 03/06/2014 05:07 AM, Jeremy Audet wrote:
In case anyone is interested, since we've received no answer, we've
decided
with /usr/share/webapps/bin/
So long as this solution interoperates nicely with web applications written with other frameworks (e.g. Flask, Django, Rails), then I trust your judgment.
--Jeremy
Thank you! I don't see why it wouldn't. Webapps written in anything use the directory /usr/share/webapps without proplems. If anything else uses the "bin" directory for a similar purpose, there still shouldn't be a problem as all PHAR packages have the ".phar" extension.
Regards, Attila
Thanks for the clarification. The ".phar" extension will effectively put all PHP apps in their own namespace, and that seems like a good conflict-avoidance mechanism to me. (Of course, other folks are free to disagree.)
--Jeremy
aur-general@lists.archlinux.org