Re: Re: phpenmod/phpdismod

Counter-view: I dislike enmod/dismod and think they're unnecessary complexity. I like that, on almost every distro, as soon as an extension is installed, it's enabled and I don't have to "jump through extra hoops". I dislike tools like this that, as I see it, have no purpose other than to avoid people learning how the tools they use work and manually editing config files. The way Composer handles this on a per-application basis is the correct method (in my opinion). Using enmod/dismod is a work-around hack. If I have other PHP processes running (possibly being automatically started and stopped - automatically controlled background workers and crons), I don't want extensions enabled / disabled for those when it's only one script that desires changes. If you have tools which don't implement xdebug-handler, and forking / submitting a PR is not an option, you can (in all the cases I can think of) write a wrapper script that achieves the same effect (copies config files to a temporary location, disables the extension(s), runs the target script specifying the new config). I would suggest perhaps what we really want here is a php commandline parameter that disables a specific extension (if enabled), which would save copying config files and simplify the above. On 18/02/2019 22:31, Gabriel Ostrolucky 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.