Add debugging support#6
Conversation
There was a problem hiding this comment.
So just to be clear, sideboard/run_server.py is already only there for debug purposes. (This is not obvious because we're not using any actual packaging, but in production the expectation is that we'd use cherryd to spin up the server.)
Even accounting for the fact that MAGFest probably uses sideboard/run_server.py in production, is there any reason not to always lockfiles on startup? If we ever have a case where Sideboard shuts down and leaves lockfiles there, I don't think we'd ever want them to stick around. So really we should just add this function to run_server.py and call it there (although it might be worth checking to see that Sideboard isn't already running before we remove the lockfiles).
There was a problem hiding this comment.
ah i actually was having supervisord use run_server.py for production, so i guess that's why I didn't want to touch it there.
it's probably a good call to make sure the lockfiles are cleared out each server run, debug or not, sure.
There was a problem hiding this comment.
Yeah, I figured we were doing that, which is fine. The public Sideboard repo doesn't have any packaging, because my old job decided to stop pushing changes and then took down the repo, so that means that we don't have a "real" init.d script for doing start/stop/restart with a pidfile and all that jazz. Which is fine, since our supervisord is doing a fine job of making sure that the service is running, though in the long run (meaning next year) it'll be great if we can do things with real packaging (like we'll be installing .deb packages and using real init.d scripts and whatnot).
Update versions of Python and Node, fix Dockerfile build
Moved these files from the ubersystem project into the sideboard project where they now belong
you can use these with PyCharm in order to do debugging
these do not affect normal operations