Run Server alias fails on working install

[daredoes]

Hey Eli, looking for some help here. I'm working on getting sideboard functional for a school project.

(env) vagrant@vagrant-ubuntu-trusty-64:~/uber/sideboard$ run_server
Traceback (most recent call last):
  File "/home/vagrant/uber/sideboard/sideboard/run_server.py", line 5, in <module>
    import sideboard.server
  File "/home/vagrant/uber/sideboard/sideboard/server.py", line 207, in <module>
    cherrypy.tree.mount(Root(), '', app_config)
  File "/home/vagrant/uber/sideboard/sideboard/server.py", line 202, in mount
    assert script_name not in cherrypy.tree.apps, '{} has already been mounted, probably by another plugin'.format(script_name)
AssertionError:  has already been mounted, probably by another plugin

This error pops up whenever I execute run_server.py.

I've had a few other errors, but I've been working my way around them.

EDIT:

More info:
This is the state of cherrypy.tree.apps when the assert fails.

{u'': cherrypy._cptree.Application(<sideboard.server.Root object at 0x7fcda7c06190>, u'')}

and it appears that the script_name its searching for is hardcoded to be ""

[binary1230]

search for all cherrypy.tree.mount() calls in your code, the second argument to that function needs to be unique in all instances. paste in any calls to that here for further diagnosis

[daredoes]

I've done a search through all files in Path. This is the only one I can find executing. It goes run_server -> import server.py -> error

[binary1230]

can you find out if it's calling cherrypy.tree.mount() twice somehow? debugger? print statements?

[daredoes]

AGH. run_server.py was importing sideboard.server or server.py which would then trigger init.py which called import sideboard.server which would double trigger the application mounting. Now I've got that understood, but I've hit a new level of weird where the logger has just turned itself off.

[EliAndrewC]

Sorry it's been a crazy week so I'm behind on Github issues and PRs. One general note: if possible you should try using the resyncing_with_public branch of this Sideboard repo, which has a lot of new features and a few bugfixes. In particular, while it wouldn't have stopped this from happening in the first place, I believe you'd have gotten a slightly less confusing error message.