patzilla
patzilla copied to clipboard
PatZilla does not serve requests when started in development mode
Hi there,
following up on the report #51 by @think-nice-things, we tried to reproduce the problem. We installed the software with:
virtualenv --python=python2 .venv2
source .venv2/bin/activate
pip install patzilla
pip install 'urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1' # Just a fix to adjust some dependency woes.
Then, we created the configuration file patzilla.ini
patzilla make-config development > patzilla.ini
and adjusted a single line, adding the depatech data source like:
[ip_navigator]
datasources = ops, depatisnet, depatech
With that, PatZilla seems to start successfully.
pserve patzilla.ini
2022-04-28 18:26:07,646 INFO [patzilla.navigator.settings ][MainThread] Root configuration file is /path/to/patzilla.ini
2022-04-28 18:26:07,646 INFO [patzilla.util.config ][MainThread] Requested configuration files: /path/to/patzilla.ini
2022-04-28 18:26:07,650 INFO [patzilla.util.config ][MainThread] Effective configuration files: /path/to/patzilla.ini
2022-04-28 18:26:09,184 INFO [patzilla.access.epo.ops.client ][MainThread] Creating OpsClientPool
2022-04-28 18:26:09,186 INFO [patzilla.access.depatech.clientpool ][MainThread] Creating DepaTechClientPool
Starting server in PID 89804.
Serving on http://0.0.0.0:6543
However, when invoking a request to http://localhost:6543/navigator/, the application croaks like
Traceback (most recent call last):
File "/Users/amo/dev/tmp/testdrive/tmp/.venv2/lib/python2.7/site-packages/pyramid_mako/__init__.py", line 148, in __call__
result = template.render_unicode(**system)
File "/Users/amo/dev/tmp/testdrive/tmp/.venv2/lib/python2.7/site-packages/mako/template.py", line 479, in render_unicode
self, self.callable_, args, data, as_unicode=True
File "/Users/amo/dev/tmp/testdrive/tmp/.venv2/lib/python2.7/site-packages/mako/runtime.py", line 883, in _render
**_kwargs_for_callable(callable_, data)
File "/Users/amo/dev/tmp/testdrive/tmp/.venv2/lib/python2.7/site-packages/mako/runtime.py", line 920, in _render_context
_exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
File "/Users/amo/dev/tmp/testdrive/tmp/.venv2/lib/python2.7/site-packages/mako/runtime.py", line 947, in _exec_template
callable_(context, *args, **kwargs)
File "/Users/amo/dev/tmp/testdrive/tmp/.venv2/lib/python2.7/site-packages/patzilla/navigator/templates/site.mako", line 29, in render_body
<%include file="urlcleaner.js"/>
File "/Users/amo/dev/tmp/testdrive/tmp/.venv2/lib/python2.7/site-packages/mako/runtime.py", line 782, in _include_file
template = _lookup_template(context, uri, calling_uri)
File "/Users/amo/dev/tmp/testdrive/tmp/.venv2/lib/python2.7/site-packages/mako/runtime.py", line 841, in _lookup_template
raise exceptions.TemplateLookupException(str(compat.exception_as()))
TemplateLookupException: Can not locate template for uri 'patzilla.navigator:templates/urlcleaner.js'
With kind regards, Andreas.
same here. The browser shows:
Internal Server Error
The server encountered an unexpected internal server error
(generated by waitress)
I believe it's related to
development_mode = true
If I set it to false, the above error disappears (but yet depatech not working, see #51).
Ah, thanks for the hint! Indeed, when setting development_mode = false, PatZilla does serve requests. We will have to improve this detail within one of the next iterations.
Dear @think-nice-things,
improvements to the documentation coming from #49 will only refer to patzilla make-config production, which would be the right thing to choose when running PatZilla acquired from the package on PyPI, as it is the case here.
patzilla make-config development is only suitable when working with the development sandbox setup, where the sources of PatZilla have been acquired from the Git repository.
Through improving the corresponding documentation, I believe it will be safe to close this issue. What do you think?
With kind regards, Andreas.
Hi again,
after scanning the issues submitted to this repository, I just discovered that @papoteur-mga already reported the same thing over at #11.
With kind regards, Andreas.