GitLab

to ease reuse and improve readability.

--HG--
branch : 3.25

a renaming could be better at some point, but that's a start.

--HG--
branch : 3.25

available_cubes should not strip cubicweb_prefix but return actual package name
for cube as package, since its output is also used to e.g. get ccplugin or
site_cubicweb module name.

Original aim of this set was to fix output of the "cubicweb-ctl list" command.
This will be done by an alternate implementation in a later cset.

--HG--
branch : 3.25

--HG--
branch : 3.25

--HG--
branch : 3.25

It has been kept since 3.24 when we merged pyramid-cubicweb and
cubicweb-pyramid repositories into cubicweb's one waiting for someone to move
the information in some canonical place but this never happened and this
information is probably not so useful or already existing elsewhere. So just
drop the file.

--HG--
branch : 3.25

--HG--
branch : 3.25

docs.cubicweb.org contains outdated documentation at the moment (and for quite
some time); until it gets update, refer to the up-to-date documentation on
readthedocs.

--HG--
branch : 3.25

The historic behavior is to hide potential exception occurring in
postcommit_event(). Unfortunately logging statements are hidden by default
during tests and it become very hard to debug. At least raise if we are in test
mode.

--HG--
branch : 3.25

--HG--
branch : 3.25

--HG--
branch : 3.25

Some people way want to run a pyramid server in debug mode without the
toolbar. This warning is annoying for them. Others should just install and
*include* the toolbar by hand.

--HG--
branch : 3.25

Otherwise the file is not installed and `cubicweb-ctl create -c pyramid` does
not work.

--HG--
branch : 3.25

As we changed this in cubicweb, there is a consensus that this
is not the best practice so let us change it as well for
skeleton.

--HG--
branch : 3.25

Document that without "bwcompat" we can use a development.ini file directly
and add a dedicated section to list configuration options.

--HG--
branch : 3.25

Again mentioning the two modes of operations and dropping references to prior
implementation.

--HG--
branch : 3.25

We drop references to pyramid-cubicweb and cubicweb-pyramid, remaining of the
merge in 3.24. We now mention the two possible operation modes
(with bwcompat being true or false).

--HG--
branch : 3.25

Which, as documented, mostly consists of internals.

--HG--
branch : 3.25

This function got renamed into config_from_cwconfig and this is arguably an
internal detail so should not appear in the API documentation.

--HG--
branch : 3.25

--HG--
branch : 3.25

Otherwise most of the cubicweb.pyramid API doc fails to build. For this we
skip installation in the "doc" environment and source the new
requirements/doc.txt which will install cubicweb[pyramid], thus pulling
cubicweb plus pyramid's dependencies.

Furthermore this requirements/doc.txt would be useful to build to
documentation on readthedocs.

--HG--
branch : 3.25

On an entity with no composite an additional item "None" was displayed.

--HG--
branch : 3.25

When the entity has two relations to the same composite, display it only once.

--HG--
branch : 3.25

--HG--
branch : 3.25

To avoid cubicweb exceptions handling.

--HG--
branch : 3.25

--HG--
branch : 3.25

The RQLRelationRewriter is instanciated for each RQL query, it should
avoid parsing computed relations formula by using a cache, which seems rightly
located on the instance's schema.

This brings a *huge* performance boost to some pages on application with a few
computed relations (x4 observed on a client app).

Kudos to Adrien, David and Sylvain.

Closes #17059828

--HG--
branch : 3.25

Most of the times, the package is not installed (not pulled by
cubicweb[pyramid] nor pyramid itself) in a fresh environment so that first
start of a new instance will fail.

--HG--
branch : 3.25

--HG--
branch : 3.25

Those are all about backward incompatibilities, keep only one section about that.

--HG--
branch : 3.25

--HG--
branch : 3.25

Instead of using "cubes path", which in many cases will be something wrong
(like <prefix>/share/cubicweb/cubes) now that cubes are regular Python
packages.

--HG--
branch : 3.25

It seems that there already is a special shutdown step for repository in test
mode and pyramid's atexit handler interferes with it leading to assertion
error about 'shutting_down' attribute being True in Repository.shutdown().

--HG--
branch : 3.25

_CubeImporter can load cube subpackages twice (there is a test for submodules
in cubicweb.test.unittest_cubes.test_no_double_import() but not with a
subpackage).

Since _CubeImporter is for backward compatibility and is supposed to be
deprecated as soon as possible, don't rely on it when loading cube schema or
appobjects and always load the real modname (eg. cubicweb_<cube> if exists else
cubes.<cube>).

--HG--
branch : 3.25

Let's make a release candidate version of CubicWeb 3.25.0 (only for the Python
package), in the hope that some issues that we usually discover after release
will be sorted out before.

--HG--
branch : 3.25

Making it clearer that this would build a Pyramid application, just in case we
eventually provide other means to create a WSGI application than Pyramid.

This is the normal way of running tox. We used to set this because
some people liked to run tests using packages installed by other
means (i.e. system-wide). Now, there seems to be a consensus that
running tox without site packages is a better idea, in particular
since many of our dependencies are now available as wheels and thus
would install quickly provided one uses a recent pip/virtualenv.

Otherwise, setuptools complains that the target installation directory (i.e.
"user site" is not in PYTHONPATH). This is probably because we use a fake HOME
with --user install option. Failure shows up when running tests through tox
without system site packages (see next patch).