Skip to content

rebase patch for VPYTHON_HTTP_PORT and VPYTHON_NO_LAUNCH_BROWSER #219

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

Merged
merged 1 commit into from
Aug 30, 2022

Conversation

danx0r
Copy link
Contributor

@danx0r danx0r commented Aug 27, 2022

This partially addresses #217, by (optionally) not launching a browser and restricting the http port to a specified port.

This allows development with an open browser on a certain port, rather than having your default browser relaunched every time you run the code.

The relevant behavior is specified by two environment vars:

VPYTHON_HTTP_PORT

and

VPYTHON_NO_LAUNCH_BROWSER

@BruceSherwood
Copy link
Member

I'm delighted with your enabling of a fixed port; the changing port number was simply a mistake on my part a long time ago and should have been fixed long ago. I suggest that we simply choose a port number, and I suggest 4200 (since "42" is the answer to everything...). I note that when using spyder a rerun really does use the existing browser page, though when using idle a rerun deletes the browser page (and the browser if only one page was open), just as with the present VPython. On the other hand, I don't understand (but am not necessarily opposed to) the need for being able to suppress the browser. It is already the case that when running in no-notebook mode no browser is invoked if there are no graphics statements in the program.

@danx0r
Copy link
Contributor Author

danx0r commented Aug 28, 2022

Hi -- thanks for reviewing my pull request.

I'm running Ubuntu, and I have multiple workspaces that I can switch between. I typically run scripts from a terminal. Whenever vpython is invoked, it creates a new browser, often in the wrong workspace and with seemingly random size and screen position -- so letting the developer set up a single browser instance in their desired location and workspace, such that they just need to refresh it occasionally rather than hunt for a new browser window is very convenient.

In the larger picture, as outlined in #217 I would love to be able to build a website around vpython using the server built into vpython7 no_browser mode, but as presently architected that appears impossible because the server itself shuts down after each run. It seems to me the components are there to run a vpython program as a REST server that responds to multiple client sessions, but the way forward on that is not clear to me yet.

@BruceSherwood
Copy link
Member

BruceSherwood commented Aug 28, 2022

From your reply, I'm not sure what your opinion is on the two issues I raised. 1) Shall we eliminate VPYTHON_HTTP_PORT and just use one port number (4200)? 2) Why is there a need for VPYTHON_NO_LAUNCH_BROWSER, given that no browser is started if the program does not use graphics statements?

@danx0r
Copy link
Contributor Author

danx0r commented Aug 28, 2022

I'm OK with default port=4200 but I would recommend allowing my suggested environment variable to override it in case of conflicts with other applications.

The reason to include VPYTHON_NO_LAUNCH_BROWSER is to enable a workflow where a browser is open and configured for testing and debugging, and does not get closed and re-opened on every test run. This may not be a problem if you always develop in an IDE such as Spyder, but if you use a stand-alone code editor and run the application from the command line it is very inconvenient to have the browser constantly close and reopen.

@BruceSherwood
Copy link
Member

Thanks for explaining VPYTHON_NO_LAUNCH_BROWSER but I would have thought that it was unnecessary. Just open a browser to some random page, and put the browser where you want it to be, with a size you want, and you'll achieve the same result, won't you?

@danx0r
Copy link
Contributor Author

danx0r commented Aug 29, 2022

Another reason to support the no-launch feature: as things work now, I am forced to use my default browser. I have both Firefox and Chrome installed, and there are good reasons to use one vs the other.

In any case, I think there is a larger issue here. My eventual goal is to build 3D applications that run on people's browsers but communicate with a server to provide the authoritative model of the system. VPython is tantalizingly close to being able to do that, but its habit of running a server and browser client for a single session and then quitting both makes this impossible.

I would encourage the VPython team to consider adding a mode of operation that would work more like Jupyter does, where a long-lived server listens on an HTTP port and clients can visit that URI:port from whatever browser or client they desire. I think this would open up a broader base of users and applications.

@danx0r
Copy link
Contributor Author

danx0r commented Aug 30, 2022

One more use case: I may want to run vpython on a server in the cloud, and view the result on my local machine. These severs are headless, so an attempt to open a browser will probably cause an exception.

@mwcraig
Copy link
Contributor

mwcraig commented Aug 30, 2022

@danx0r -- we'd like to go ahead with this and also set a fixed default port (leaning towards 4200). You could add that change to this pull request or we can do it in a separate PR.

Either way can you please add your name to this file: https://github.com/vpython/vpython-jupyter/blob/master/CONTRIBUTORS.md

I'm not sure how much effort the new mode would be, but this hopefully addresses the immediate issues.

@mwcraig
Copy link
Contributor

mwcraig commented Aug 30, 2022

I'm going to go ahead and merge this -- PR #220 adds @danx0r as a contributor.

@mwcraig mwcraig merged commit 4469d3a into vpython:master Aug 30, 2022
@danx0r
Copy link
Contributor Author

danx0r commented Aug 30, 2022

Note that an old open PR #111 appears to cover the same ground and can probably be closed (not applied)

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

Successfully merging this pull request may close these issues.

None yet

4 participants