Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote PsySH #121

Open
bayleedev opened this issue Dec 13, 2014 · 19 comments
Open

Remote PsySH #121

bayleedev opened this issue Dec 13, 2014 · 19 comments

Comments

@bayleedev
Copy link

Since PHP is usually ran by apache, it would be nice for psych to open up a socket connection or something, and allow you to connect to it remotely, or on the same box that way you aren't limited in debugging things you run from the command line.

@bobthecow
Copy link
Owner

Yes. That is the (eventual) plan. If you'd like to see it sooner, we'd happily accept a pull request :)

@bayleedev
Copy link
Author

@bobthecow I started working on this and ran into a few ways of doing it. I sent you an email, maybe you could point me the right direction on how you would like to see it going? I could paste it in here if that makes it easier.

@bobthecow
Copy link
Owner

Yes, you did. Sorry, I haven't had a chance to answer. I'll get on that :)

@bayleedev
Copy link
Author

What about an input_server on one port, and output_server on another port. The client would connect to both of them based on the configuration. That way we keep the same abstraction we have now, but we'd have to maintain two connections. Thoughts?

@bobthecow
Copy link
Owner

I originally thought that this would be a good opportunity to refactor a bit of the PsySH internals and make it use more of a client/server model for regular use as well. Essentially, split out the readline/input and stdout/output into a "Client", and move the execution loop into a "Server", both of which are owned by the Shell app.

This way you could use stream_select to handle input from readline/input, and output from stdout/output. It would make everything more responsive. It would make it possible to interrupt long running operations with ctrl-c without killing the entire shell. It would mean that the actual "doing work" part of psysh would simply be receiving code to evaluate and returning a string with output. psysh commands could then run on the "client" for the most part, but reach over to the "server" when they needed to interact with state. And ultimately, it would open the door for a lot more "client" types — a socket.io-based web client, a console based command to make one psysh instance into a client for another, etc.

The more I think about it, the deeper this rabbit hole gets, though, so it might be worth writing a simpler version now and working toward that in the future :)

@bobthecow
Copy link
Owner

The bare minimum you'd need is a socket-based \Psy\Readline, a socket based \Psy\Output\ShellOutput, a way to get \Psy\Shell to open up a pair of sockets and use those instead of the default input/output pair, and a way to connect as a "client". This should either be a web based client or a psysh command… the command version seems like a simpler place to start?

@Markcial
Copy link
Contributor

a little teaser :
screenshot from 2015-02-24 15 16 01

the downsides, some more dependencies, looking if they are really necessary.

@bobthecow
Copy link
Owner

:)

@jakefolio
Copy link

Any progress on this? Is there a branch or fork where it's being worked on @Markcial?

@Markcial
Copy link
Contributor

I had in fact a experiment that worked, but needs heavy refactor of the shell class, in order to have the experiment working the shell needs a public api of the eval method, so a websocket server is listening for incoming connections and preserve the context. I will dig back in time in my git history, maybe the experiment is still there, ping you back in a couple of days.

@theofidry
Copy link
Contributor

That would be awesome

@bayleedev
Copy link
Author

Any update on this?

@mikedfunk
Copy link

+1

@Markcial
Copy link
Contributor

I know that it would be a killer feature. I heavily tried to get it working successfully, but the inner design of PHP makes really hard to share states and object representations between PHP threads. And PHP is meant to be used as a single shot worker, not a daemon serving data.

The feature would work for simple variables and states that can be easily serialized in json, but not for complex objects that might include things like sockets, resources, closures, and so on.

For unserializable objects this feature would be a complete dead end, i am sorry about this.

I will try to post the source of the samples, but i will have to start again from scratch because seems that i lost the source on some backup.

@bayleedev
Copy link
Author

@Markcial, maybe we should start by getting in the abstraction layer that just works for the current implementation so this isn't such a large project? You probably already have this done, so maybe just tear the rest out for now? Or maybe there's another way to break up this work?

It seems like there is a LOT of interest, so making this a more iterative approach is probably the best option.

@theofidry
Copy link
Contributor

Another solution would be to replace the interactive shell of the IDE when
using xdebug.

On Friday, 18 March 2016, Blaine Schmeisser notifications@github.com
wrote:

@Markcial https://github.com/Markcial, maybe we should start by getting
in the abstraction layer that just works for the current implementation so
this isn't such a large project? You probably already have this done, so
maybe just tear the rest out for now? Or maybe there's another way to break
up this work?

It seems like there is a LOT of interest, so making this a more iterative
approach is probably the best option.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#121 (comment)

@Markcial
Copy link
Contributor

I appreciate the interest on this feature but currently i have a lot of code waiting for review that would imply subsequent newer features, the code completion currently needs some eval of the current object for example, currently the PySH shell doesn't haves a somewhat public api for evaluating objects. The interactive shell via browser needs too that public api for evaluating.

There is a lot of stuff going on, and before getting this thing done, those features would need get to master, not all, but the ones that imply a non forking process for object preservation instead of serialization and the other one that exposes the shell execution to a public method.

Non forking process loop => #163
Public api for the execute method in the shell => #138

What i mean, if you really want a feature like that, start doing code reviews of the currently pending PR i did long time ago, and maybe we can do a fresh start via a more extensible PySH shell.

/cc @bobthecow

@castarco
Copy link
Contributor

@Markcial meanwhile, there is a PHP "kernel" for Jupyter. It's far from perfect, but it's based on PsySH and takes advantage of the Jupyter Notebook frontend, Nteract and other frontends... :

@tgr
Copy link
Contributor

tgr commented Dec 11, 2022

As with #505, this would increase the security footprint of PsySH significantly. I can see it being very useful, especially on crappy webhosts which do not give SSH or XDebug access so debugging applications can be a nightmare, but IMO it should be split off into a separate package, as CLI PsySH can be very useful in a production environment, while installing code for a network backdoor (which would presumably be off by default, but code and configuration mistakes happen) seems like invitation for trouble.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants