Re: Re: phpenmod/phpdismod

php.internals

Legale Legage

7 years ago
I have made super simple OS independent phpenmod. Https://github.com/legale/phpenmod On Feb 18, 2019 23:31, Gabriel Ostrolucky <gadelat@gmail.com> wrote: > > I'm fan of this idea. I miss this in any other non-debian distro. > What nobody mentioned yet, similar script (dockerphp-ext-enable) > is used in PHP docker images. You can check them out at > https://github.com/docker-library/php/blob/master/7.3/alpine3.9/cli/docker-php-ext-enable > > However, enabling extensions in PHP via CLI is easy. > It's just php -dextension=extension.so. What isn't easy, is DISABLING them.  > > This is very important to do when you have profiling/debugging extensions > like xdebug enabled. > > Currently, PHP community needs to do workaround gymnastics because of this > missing functionality. Check > https://stackoverflow.com/questions/31083195/disabling-xdebug-when-running-composer > and xdebug-handler created as a result > https://github.com/composer/xdebug-handler/blob/master/src/XdebugHandler.php > > Now, authors of CLI tools ship this xdebug-handler and unload it by default. > This makes their software faster by default, but all the CLI tool authors > must depend on this. And users are less aware of what's going on. > > If you are a consumer and your CLI tool does not depend on it, > you are out of luck, back to editing .ini files by hand - or > wondering why is the tool slow or even abandoning it because of that. > If you are a consumer and want to debug your CLI tool using it, > you will spend some time figuring out why it doesn't work. > > I know I went little offtopic here, since this thread is mainly about script > which persists these settings, instead of just CLI switch, but I think this > was worth mentioning, as it complements it. IMO hard to edit ini files are > frustrating mainly because of lacking quick way for disabling extensions. > Having a CLI swith do not only ENABLE extension, but also DISABLE it, would > help a lot and shipping script for modifying ini files might be a lot smaller > necessity after that. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >

Marco Pivetta

7 years ago
Seems like this still modifies the environment. As a non-privileged user (such as a running production Docker environment) you: 1. cannot touch the filesystem 2. Should be able to add a single flag to the terminal, such as it currently happens with `-dextension=...`, but with opposite effect On Mon, 18 Feb 2019, 23:39 Legale.legale <legale.legale@gmail.com wrote:

Peter Kokot

7 years ago
On Mon, 18 Feb 2019, 23:39 Legale.legale <legale.legale@gmail.com wrote:
> I have made super simple OS independent phpenmod. > > Https://github.com/legale/phpenmod > On Feb 18, 2019 23:31, Gabriel Ostrolucky <gadelat@gmail.com> wrote: > > > > I'm fan of this idea. I miss this in any other non-debian distro. > > What nobody mentioned yet, similar script (dockerphp-ext-enable) > > is used in PHP docker images. You can check them out at > > > https://github.com/docker-library/php/blob/master/7.3/alpine3.9/cli/docker-php-ext-enable > > > > However, enabling extensions in PHP via CLI is easy. > > It's just php -dextension=extension.so. What isn't easy, is DISABLING > them. > > > > This is very important to do when you have profiling/debugging > extensions > > like xdebug enabled. > > > > Currently, PHP community needs to do workaround gymnastics because of > this > > missing functionality. Check > > > https://stackoverflow.com/questions/31083195/disabling-xdebug-when-running-composer > > and xdebug-handler created as a result > > > https://github.com/composer/xdebug-handler/blob/master/src/XdebugHandler.php > > > > Now, authors of CLI tools ship this xdebug-handler and unload it by > default. > > This makes their software faster by default, but all the CLI tool > authors > > must depend on this. And users are less aware of what's going on. > > > > If you are a consumer and your CLI tool does not depend on it, > > you are out of luck, back to editing .ini files by hand - or > > wondering why is the tool slow or even abandoning it because of that. > > If you are a consumer and want to debug your CLI tool using it, > > you will spend some time figuring out why it doesn't work. > > > > I know I went little offtopic here, since this thread is mainly about > script > > which persists these settings, instead of just CLI switch, but I think > this > > was worth mentioning, as it complements it. IMO hard to edit ini files > are > > frustrating mainly because of lacking quick way for disabling > extensions. > > Having a CLI swith do not only ENABLE extension, but also DISABLE it, > would > > help a lot and shipping script for modifying ini files might be a lot > smaller > > necessity after that. > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > >
For more portability - systems suppory (Linuc, mac, bsd etc) and still no Windows instead of the #!/bin/bash use the shebang #!/bin/sh Also, this tool mostly is still tied to current Linux repositories and not to a php built from sources... So that's another thing making it specific to certain installation type. I'd still say that the tool needed for PHP is renewed and completwly rewritten pecl. Basically copy paste of current functionality in its essense and adding more swag and user features. Something like that...

Johannes Schlueter

7 years ago
On Mo, 2019-02-18 at 23:39 +0100, Legale.legale wrote:
> I have made super simple OS independent phpenmod.  >   > Https://github.com/legale/phpenmod
This won't replace Ubuntu's version since on Ubuntu different SAPIs use different ini dirs. Functionality-wise it is also no replacement as Ubuntu's also handles priorities (.e. to load mysqlnd befoe mysli or xml before dom) also it doesn't handle zend_exensions. The script also doesn't support setups where PHP is not in $PATH or has an binary pre-/suffix (what some people do to have different versions in $PATH) I'd also suggest to look at `php --ini` instead of `php -i`. Thus the script might be useful for some setups. A generic solution however is not trivial. johannes