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

Start web server after building the documentation #2574

Conversation

joschmitt
Copy link
Member

@joschmitt joschmitt commented Jul 19, 2023

As discussed in Slack, the open_browser option of build_doc does not work (at least) on Ubuntu's sandboxed snap-firefox. I added a comment regarding this to the documentation (first commit).
@benlorenz suggested to start a web server using LiveServer.jl in the build directory, so I also tried this.
I'm not really familiar with the setup for building the documentation and eventually added LiveServer as a dependency at every place I could find because this seemed to be the only way to make it work. Is there a better way and do we want to have this dependency at all?

As of now this will of course simply start the server, but not update anything, when the user edits the documentation (like the LiveServer.servedocs function claims to do).

@joschmitt joschmitt force-pushed the my_browser_knows_better_what_to_open_than_me branch from 3bf1ade to 30901b6 Compare July 19, 2023 14:55
@benlorenz
Copy link
Member

I don't really like adding it as a dependency.
Maybe we can just run it via a separate julia process and keep the liveserver process in the background, storing the process object in a variable to make sure we start it only once. (Stopping it with a Base.atexit hook).

The command line might look like this:

julia -e 'using Pkg; Pkg.activate(temp=true); Pkg.add("LiveServer"); using LiveServer; LiveServer.serve(dir="$(docspath), open_browser=$(open_browser)");'

I don't know if we want to try to integrate the servedocs variant, it does not work for adjusted docstrings anyway (only .md files). Maybe the best approach is to have users run the normal docs build again (with Revise) and keep the server + browser running, just refreshing the page after the build is done again.

@codecov
Copy link

codecov bot commented Jul 19, 2023

Codecov Report

Merging #2574 (7af4c60) into master (e38b18b) will increase coverage by 0.00%.
Report is 1 commits behind head on master.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master    #2574   +/-   ##
=======================================
  Coverage   73.20%   73.20%           
=======================================
  Files         446      446           
  Lines       63676    63678    +2     
=======================================
+ Hits        46615    46618    +3     
+ Misses      17061    17060    -1     
Files Changed Coverage
src/utils/docs.jl 0.00%

@joschmitt joschmitt force-pushed the my_browser_knows_better_what_to_open_than_me branch from 30901b6 to 4e9c25c Compare July 20, 2023 08:32
@joschmitt
Copy link
Member Author

Here is a version that starts LiveServer as a background process. For me, this is fine, but there are some nuisances:

  • If the background process fails, the user will not get any feedback. I tried to redirect stderr (but not stdout) for this, but somehow one either gets stderr AND stdout or nothing?
  • If there is already something running at port 8000, LiveServer chooses another port and I have no idea how to find out which (other than reading the output from stdout...).
  • If one kills the main julia process via SIGKILL, the atexit does not get executed and the background process stays alive.

@joschmitt joschmitt marked this pull request as ready for review July 20, 2023 08:43
@joschmitt
Copy link
Member Author

joschmitt commented Jul 20, 2023

Looks like another occurrence of #2541 (in this case not on nightly).
Well, not any more.

@joschmitt
Copy link
Member Author

joschmitt commented Jul 24, 2023

Small update on my comments above: one can in fact redirect only stderr, it's just that Pkg.activate prints to stderr by default, but one can also redirect that. Then again, I'm not too convinced any more that one should print the stderr of the background process to the calling julia session as it will just result in out-of-context error messages.

@benlorenz
Copy link
Member

I am still in favor of doing this, but I would love some other opinions on whether we should add this.

Maybe we should put live_server_process in a global variable to be able to check whether it is still running when calling the function a second time?
And I think hiding the error output should be fine.

@joschmitt
Copy link
Member Author

There was a short discussion on this in the Wednesday's meeting in Kaiserslautern:

  • Potentially @aaruni96 is interested in this
  • We could consider the (third?) option of providing the functionality in principle, but telling the user to install LiveServer by themselves, if they want to use it.

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't tested this, but it looks great, thanks!

src/utils/docs.jl Outdated Show resolved Hide resolved
src/utils/docs.jl Outdated Show resolved Hide resolved
@joschmitt
Copy link
Member Author

As far as I know, @aaruni96 wanted to work on an alternative solution... For the record, the following approaches have been mentioned/tried out:

  1. Add LiveServer.jl as a dependency. We don't want that.
  2. Start a background process that installs LiveServer.jl in a temporary environment and starts the server (the current state of this PR). Comes with some drawbacks, most notably that we start a background process. We could improve the interface a bit by remembering in a global variable (or maybe we can even check?) whether a server is already running.
  3. Only provide a function that starts the server and tell the user that they have to install LiveServer.jl themselves. Would also be fine for me; the test_module function also tells you that you need to do using Test after all.
  4. Aaruni's multithreading solution.

(Un)fortunately, I'm on holidays the next two weeks, so if I am further involved in this it has to wait until after that.

@aaruni96
Copy link
Member

I apologize, I was refreshing some julia multiprocessing while thinking about this PR and forgot to update here.

The solution I propose such:

We can spawn a julia worker process (addprocs() from Distributed) , and ask it to load LiveServer in a temporary environment. We can then check if the server is still running by asking the status of the future, or kill it by sending an interrupt to the worker.

This would require adding Distributed to Oscar dependencies (currently, its only a dependency for the tests).

The solution should work on single core CPUs as well (the OS can schedule multiple jobs), but its something I am not fully sure about.

@fingolfin
Copy link
Member

@aaruni96 I think adding a dependency on the stdlib Distributed is fine, so feel free to go ahead with providing an alternate PR.

@joschmitt joschmitt marked this pull request as draft August 23, 2023 10:24
@fingolfin
Copy link
Member

@aaruni96 look into an alternative implementation, but it turns out that the approach here also allows some control over the subprocess running the webserver (should we want to), which we were unaware of before. So the main reason for an alternate approach really does not hold.

So I would just merge this PR -- we can still improve it later, if we want to (as with any feature).

@joschmitt you marked it as draft again -- I assume because of our discussion, but I want to double check just in case you had other reasons?

src/utils/docs.jl Outdated Show resolved Hide resolved
Pkg.add(\"LiveServer\"); using LiveServer;
LiveServer.serve(dir = \"$build_dir\", launch_browser = $open_browser, port = $port);"
live_server_process = run(`julia -e $cmd`, wait = false)
atexit(_ -> kill(live_server_process))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you verify this works? Because when I just tried this by copy&pasting this code, kill was just ignored. I suspect this was because I am using juliaup, which actually forks julia into a subprocess...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay... I'm very sure it worked for me at some point. I will try again.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So yes, for me it works.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you try again? Maybe it is fixed by 7af4c60 as @benlorenz suggested.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried it now with juliaup and it works (with 7af4c60). Without that commit it doesn't, so I assume that this is fixed.

@joschmitt
Copy link
Member Author

@joschmitt you marked it as draft again -- I assume because of our discussion, but I want to double check just in case you had other reasons?

Yes, I wanted to avoid that somebody merges this "accidentally". Let me add your suggestions and then I will mark it as ready for review.

@joschmitt joschmitt force-pushed the my_browser_knows_better_what_to_open_than_me branch from 8651691 to c09de4c Compare August 30, 2023 13:35
@joschmitt joschmitt marked this pull request as ready for review August 30, 2023 13:36
src/utils/docs.jl Outdated Show resolved Hide resolved
Co-authored-by: Benjamin Lorenz <benlorenz@users.noreply.github.com>
@fingolfin fingolfin merged commit d42af1a into oscar-system:master Aug 31, 2023
13 of 15 checks passed
@joschmitt joschmitt deleted the my_browser_knows_better_what_to_open_than_me branch September 1, 2023 07:23
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.

4 participants