Philippe Pepiot <philippe.pepiot@logilab.fr> [Fri, 26 Oct 2018 17:12:26 +0200] rev 12357
Make test database template creation concurrent
build_db_cache() is used in tests to create test database templates, i.e.
DEFAULT_EMPTY_DB_ID (which is __default_empty_db__) and custom template
database using CubicwebTC test_db_id/pre_setup_database API.
When running tests in parallel using multiple processes, build_db_cache() may
try to build the same database twice. Avoid this by adding synchronisation of
process by using a file lock.
So when two processes require the same template database, one build the
database and others wait it to be created.
Use filelock (https://github.com/benediktschmitt/py-filelock) library to have a
portable (unix / windows) way for handling locks.
Also filelock is packaged in debian: https://packages.debian.org/source/python-filelock
Philippe Pepiot <philippe.pepiot@logilab.fr> [Fri, 26 Oct 2018 17:00:05 +0200] rev 12356
Make test database cache lookup concurrent
has_cache() is used to dertermine if the template database already exists or
not.
When running tests accross multiple process, has_cache() wasn't aware of
databases created by other processes because it used a cache to generate the
cache...
Since the discovering discover_cached_db() time is quite reasonable (it's just
about listing file in a directory), let re-generate the cache on cache miss.
Philippe Pepiot <philippe.pepiot@logilab.fr> [Mon, 29 Oct 2018 10:04:31 +0100] rev 12355
Fix flake8 issues since release 3.6.0
Flake8 had a new release which raise new issues, namely:
W504: line break after binary operator
F841: local variable 'ex' is assigned to but never used
W605: invalid escape sequence
F821: undefined name 'buffer' (noqa seems the only way to avoid this false positive)
Also pin flake8>=3.6 in our tests and make explicit that we use python3 to run
flake8 tests.
Philippe Pepiot <philippe.pepiot@logilab.fr> [Mon, 29 Oct 2018 10:09:19 +0100] rev 12354
Stabilize flake8 tests on 3.26 branch
Use basepython=python2 or flake8 installed with python3 will raise "[F821]
undefined name 'buffer'"
Pin flake8 < 3.6 which has new checks that doesn't pass on our current code base.
Laurent Wouters <lwouters@cenotelie.fr> [Tue, 09 Oct 2018 16:24:12 +0200] rev 12353
Fix typo in RDFS URI
Denis Laxalde <denis.laxalde@logilab.fr> [Tue, 02 Oct 2018 16:04:52 +0200] rev 12352
[doc] Do not rely on lgc's sphinx_ext
This module is broken (getting an ImportError) and I don't want to fix
it. The only usage we make of it is for the "autodocstring" directive,
and I don't know what it does.
Based on the context, replacing autodocstring with either automodule or
autoclass and removing sphinx_ext from required Sphinx extensions.
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 06 Sep 2018 13:44:06 +0200] rev 12351
Added tag 3.26.7 for changeset ee4ad63c91e5
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 06 Sep 2018 13:43:56 +0200] rev 12350
[pkg] Version 3.26.7
Philippe Pepiot <philippe.pepiot@logilab.fr> [Fri, 24 Aug 2018 17:19:02 +0200] rev 12349
Fix possible double import of cubes
For a new-style cube, if we import "cubicweb_<name>" and then import
"cubes.<name>", the cube will be imported twice. cubes.<name> and then
cubicweb_name is ok though...
When using pyramid, we try to find which cube define a "includeme" by importing
them with the name "cubes.<name>", so we (possibly ?) double import all new-style cube.
This case may also occur in tests with PyramidCWTest.
Touching the import loader to fix this scares me, so let's fix this by testing
"cubicweb_<name>" *before* "cubes.name" (for old style cubes, importing
cubicweb_<name> raise ImportError).
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 22 Aug 2018 16:04:39 +0200] rev 12348
[autoform] Make RelationField.fromcardinality a class method factory
Instead of having the "RelationField" class hard-coded in this factory
method (thus preventing any subclass to properly use it), we make that
method a classmethod and instantiate the actual class instead of the
base one.