Manipulate Configuration from within REPL

[phil-s]

The Configuration object provides methods such as setPager(), setRequireSemicolons(), setErrorLoggingLevel(), etc, which it would be nice to have access to directly from the REPL (if doing so at that stage would actually take effect?)

I note that $__psysh__->config is private (and that in any case LeavePsyshAlonePass.php throws an exception if you attempt to touch the $__psysh__ object), so there's seemingly no direct access to this.

Is there another way to invoke those methods?

[bobthecow]

I'm not opposed to this, but it's not as simple as just exposing the config object.

If it were possible to change configuration at runtime, I would probably do it via a command (config set --require-semicolons?) rather than direct access to $__psysh__->config. The difficulty with exposing it directly is that it's a combination configuration object and DIC, and there are quite a few things that simply can't be changed at runtime.

Some don't make sense to change. Some would need to swap out service implementations as config changes (readline, forking loop, etc). Actually you couldn't swap out the forking loop for a non-forking loop at runtime, so that would go in the "doesn't make sense to change" camp.

[phil-s]

Something like config set --require-semicolons would be perfect, although in the interests of minimising the potential for naming conflicts, perhaps psysh would be a better command name than config ?

FYI I'd quite like it if there were analogous command-line arguments as well, so that psysh instances could be started with particular configs without the need for config file editing. That's a different feature request to this one of course, but I mention it now in case you also see utility in that feature, and think there would be some cross-over on the implementation side.

[bobthecow]

What valid PHP code do you think config set --require-semicolons might conflict with? :)

Honestly, this would be possible, but a non-trivial amount of work to get fully working. How do you see yourself using this? Why not just spin up another session rather than changing configuration at runtime?

[phil-s]

What valid PHP code do you think config set --require-semicolons might conflict with? :)

My specific use case is with Drupal and the drush core-cli (aka drush php) command, which invokes psysh. I'm not sure whether what they've done is unexpected, but other drush commands can be invoked by name directly from the psysh prompt. Hence entering cc all in psysh is the same as running the drush cc all command.

As Drupal code is able to implement new drush commands arbitrarily, all that is needed is for a drush config command to be available, and it would conflict. As config is such a generic term, this does not seem a particularly unlikely scenario.

Why not just spin up another session rather than changing configuration at runtime?

(a) That would necessitate recreating the state of the original session before 'continuing' with the new configuration, which might require a lot of steps to do (assuming there are no complicating factors making it difficult to do at all).

(b) AFAIK I would then have to create multiple psysh config files with all the different permutations of options I would want to use, in order to run an instance with a particular set?

A command to change the config values at runtime would be vastly more convenient.

[bobthecow]

But what values, specifically, do you want to change at runtime?

[phil-s]

At minimum I think the three I mentioned initially are all useful candidates: pager, requireSemicolons, errorLoggingLevel. I would think that anything which can be set at runtime would be good to include, though.

It was a wish to interactively change the pager config which prompted me to write this, as essentially I wish to call psysh from a dumb terminal as well as from fully-featured terminals, and of course paging doesn't work in a dumb terminal. The dumb terminal use-case is due to wanting to switch my Emacs integration with drush php from using a terminal emulator buffer to using comint-based integration (which provides only dumb terminal emulation, but is otherwise a smoother experience -- and the lack of paging is more or less inconsequential when the output is going to a text editor buffer).

I created a separate config file and used the PSYSH_CONFIG environment variable to get the comint use-case to work, but that then means I need to set up an equivalent configuration file in every environment, which seems very awkward to me; whereas I can trivially arrange to automatically execute psysh commands when my comint code runs.

Being able to interactively modify settings would not only be a nicer solution to that particular need, but I think it would also be of general utility to users. For instance one could then paste a block of instructions into the shell which included temporarily setting a config value, evaluating some PHP, and then resetting the config value.