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
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
> 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
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 t
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