GitLab

see: https://forge.extranet.logilab.fr/open-source/logilab-database/-/blob/f69e3ea2fc0545e719bfd0910f0de0b14458d186/CHANGELOG.md

--HG--
branch : 3.27

related: #301

--HG--
branch : 3.28

--HG--
branch : 3.29

--HG--
branch : 3.27

related: #287

--HG--
branch : 3.27

--HG--
branch : 3.26

This avoid pip pulling a version that does not run on python2 when using a
python2 environment.

Since we already released some 3.27 releases in pypi, I think we should release
3.27.3 and remove releases 3.27.2, 3.27.1 and 3.27.0 from pypi.

--HG--
branch : 3.27

Followup a9025212ce0c

PyCryptodome comes in two flavors: “an almost drop-in replacement for the old
PyCrypto library” and “a library independent of the old PyCrypto”. The former
uses the Crypto namespace, and is shipped as `pycryptodome` while the latter
uses Cryptodome instead and lies in the `pycryptodomex` package.

Given the reason to switch to PyCryptodome is that PyCrypto in unmaintained,
its probably better to avoid any mistake and mandate the specific usage of
the Cryptodome namespace by requiring `pycryptodomex` instead of
`pycryptodome`.

A more present reason is that Debian buster will only provide a package
with the separate namespace flavor. The current Recommends is not working with
the current code. Although it's important to note that the package name will
probably have to be changed to `python3-pycryptodomex` once
https://bugs.debian.org/886291 is solved.

pycrypto isn't maintained anymore, the last release 2.6.1 is from 2014.

Use the drop-in replacement fork pycryptodome instead.
pycryptodome is packaged in debian starting from stretch-backports.

This mostly consists in removing the dependency on "six" and updating
the code to use only Python3 idioms.

Notice that we previously used TemporaryDirectory from
cubicweb.devtools.testlib for compatibility with Python2. We now
directly import it from tempfile.

Twisted web server is not used anymore and has been superseded by
pyramid many years ago. Furthermore, our usage is not compatible with
Python 3. So we drop the "etwist" sub-package.

As a consequence, "all-in-one" configuration type gets dropped as it was
Twisted-specific. We resurrect it in cubicweb/pyramid/config.py by only
keeping options used by the "pyramid". Similarly, we introduce a
AllInOneCreateHandler in cubicweb/pyramid/pyramidctl.py that is
basically the one that lived in cubicweb/etwist/twctl.py and is used to
create the "all-in-one" instance. Added a TODO here about "pyramid.ini"
that could be generated at the end of bootstrap() method.

In cubicweb/devtools/httptest.py, CubicWebServerTC is now equivalent to
CubicWebWsgiTC and the latter is dropped.

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

Thus getting rid of the last piece of data in "shared" directory.
As a consequence, we can drop data_files from __pkginfo__.py.

Related to #17132990.

--HG--
branch : 3.26

We drop the custom get_packages() function in setup.py that used to look
for test files (not discovered automatically since test directories are
not packages) and replace it by explicit entries in MANIFEST.in.

Dunno what this is for. Let's see if this work without.

Not sure what this is for, the comment mentions "egg" directory, but
this is quite likely an old hack that should be unnecessary when using a
recent setuptools.

http://setuptools.readthedocs.io/en/latest/setuptools.html#automatic-script-creation

The custom install_lib command appeared to be meant to install package
data, as declared in __pkginfo__.py. Let's rely on setuptools'
include_package_data[1] option to handle this.

[1]: http://setuptools.readthedocs.io/en/latest/setuptools.html#including-data-files

while keeping bw-compat with 1.6 - 2.7 is not available for all distributions,
e.g. jessie.

The dependancy has been bumped in 6186cd15a46d because of a change in
bc9d901cb9e6. We may easily use the appropriate method depending on the version
installed.

--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.

And use a LRU cache over cached_build_user function.

This looping task is problematic because it would not be run from within a
WSGI application which does not have a repository with a tasks manager.

This pulls an explicit dependency on 'repoze.lru' but it's not a big deal
since pyramid already depends on this. RPM spec file not update since it does
not even mention pyramid...

The application definition is actually not specific to the final "cube" being
bootstrapped from skeleton. This patch thus move the pyramid application
function into cubicweb.pyramid module and let cubicweb register the
"paste.app_factory" entry point (instead of the bootstrapped cube).

Useless call to `config.scan` is dropped along the way.

We're using a deprecated API and are getting the following deprecation
warning:

::

    the method passlib.context.CryptContext.encrypt() is deprecated as of
    Passlib 1.7, and will be removed in Passlib 2.0, use CryptContext.hash()
    instead.

So let's make sure we're getting a working library.


[ci skip]

--HG--
branch : 3.24

With the new package layout (everything under "cubicweb" package), the custom
install_lib rule which makes use of include_dirs defined in __pkginfo__.py did
not prepend the package name to source directories to be copied. Fixing this.

Also, in setup.py's export() function, the destination directories' path to be
created during source tree walk was wrong.

All this makes cubicweb/skeleton directory (which is not a package) properly
installed by setup.py.

The test in cubicweb/devtools/test/unittest_devctl.py wasn't properly
implemented because it used an installation of cubicweb in "develop" mode
which shadows such packaging issues. Also it used "python -m cubicweb" instead
of directly "cubicweb-ctl" and the former appears to fall back to using the
cubicweb package *from sources* instead of the installed one.

Now that this test runs against the installed version of cubicweb, fix
MANIFEST.in to include tox.ini files (cubicweb's and skeleton's) as this is
expected from the test.

Closes #14127941.

--HG--
branch : 3.23

Make debugging easier.

--HG--
branch : 3.23

--HG--
branch : 3.23