Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 15 Mar 2017 08:27:45 +0100] rev 12058
[repo] Drop cache clearing methods from the source interface
Those are actually system source specific.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 15 Mar 2017 08:04:58 +0100] rev 12057
[repo] Move and rename repo._clear_planning_cache
to make it clearer it's clearing the @cache of source_defs method.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Fri, 10 Mar 2017 10:10:44 +0100] rev 12056
[sobjects] Fix flake8 errors in services.py
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 15 Mar 2017 08:39:51 +0100] rev 12055
[test] Rename BaseQuerierTC._access to BaseQuerierTC.admin_access
so it's consistent with CubicWebTC and avoid access to a protected attribute
which has been exposed by the removal of the 'session' property a few csets
earlier.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 15 Mar 2017 09:15:32 +0100] rev 12054
[repo] Fix flake8 error
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 09 Mar 2017 16:36:33 +0100] rev 12053
[pyramid] Add a "pyramid" instance configuration type
In a new module 'cubicweb.pyramid.config' we define a "pyramid" instance
configuration type. The noticeable feature of this configuration is that it
manages a 'development.ini' file that gets installed in application home
(along with `.conf` file). This file is templated and includes generated
values for secrets of session and authtk tokens.
This means that we can just call:
pserve etc/cubicweb.d/<appname>/development.ini
or
gunicorn --paste etc/cubicweb.d/<appname>/development.ini -b :8080
just after instance creation to get a pyramid instance running without having
to hack around a 'pyramid.ini' file.
This patch drops 'development.ini' from skeleton and moves it in
cubicweb/pyramid so that it gets installed at instance creation which is more
appropriate than in cube creation.
The new configuration class sets "cubicweb.bwcompat" setting to false so it is
not intended to replace the "all-in-one" configuration type (which would
require a bit more work). This configuration is close to the the 'repository'
configuration type with just a couple of options from WebConfiguration that
are needed for Pyramid (anonymous user/password plus some miscellaneous
options that I'm not so sure are really needed). Note, in particular, that we
do not pull CORS settings to be injected as a WSGI middleware like in
wsgi_application_from_cwconfig() since I believe this should be left as an
end-user responsibility and since this can be defined in a standard way in
paste configuration. This configuration inherits from ServerConfiguration but
registers the same appobjects as WebConfiguration.
In cubicweb.web.request._CubicWebRequestBase, we guard against access to
"uiprops" and "datadir_url" of the config because this new "pyramid" config
does not have these (this does not make sense without bwcompat mode). At some
point, we should either avoid using `cw_request`'s pyramid request attribute
or make cubicweb's web request really independant of existing implementation
and drop these assumptions.