phpenmod/phpdismod

6 years ago by Legale.legale — view source — reply

unread

I have made super simple OS independent phpenmod.

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.

6 years ago by Marco Pivetta — view source — reply

unread

Seems like this still modifies the environment. As a non-privileged user
(such as a running production Docker environment) you:

cannot touch the filesystem
Should be able to add a single flag to the terminal, such as it
currently happens with -dextension=..., but with opposite effect

I have made super simple OS independent phpenmod.

Https://github.com/legale/phpenmod

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.

6 years ago by Peter Kokot — view source — reply

unread

I have made super simple OS independent phpenmod.

Https://github.com/legale/phpenmod

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.

--

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

6 years ago by johannes@schlueters.de — view source — reply

unread

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