GitLab

This was not necessary anymore with promoted usage of the new data import API.
Turn repository's _type_extid_cache to _type_cache with only the entity's type
as key.

This introduces an backward incompatible change: entity_metas dict doesn't
contains anymore the extid key, but it doesn't seem used at all anywhere, so
this sounds acceptable.

Closes #15538317

It not used anymore thanks to previous patches.

Closes #15538288

Simply check if entities have a cw_source, and link it to the system source when not found.

Related to #15538288

Without this, test were randomly failing within tox due to different order of solutions.

This was necessary in the "true multi-sources" time, it's not anymore, while
maintaining this index is costly.

Related to #15538317

Having TestServerConfiguration and alike in the test module namespace causes
pytest discovery errors, because it thinks it's a test class.

* update some copyright
* drop most __docformat__ declaration
* fix some flake8 warnings / errors

The latter is deprecated in favor of the former which has been introduced on cnx
to replace it.

It shouldn't rely anymore on cnx.entity_metas which is itself deprecated, and
the cw_metainformation API is similarly not needed anymore, access directly to
cwuri / cw_source if needed.

Related to #15538288

We don't want to handle anymore the entities.asource column so we shouldn't use
those anymore. Also rename repository's _type_source_cache into
_type_extid_cache as this is what it's containing now.

Do similar renaming to the system source API.

Related to #15538288

We should not need that. It has been introduced to handle things we should not
do and probably don't do anymore (e.g. attempting to grasp recursive import of
several sites).

Related to #15538288.

Related to #15538288

both are relying on the 'entities.source' column which has been dropped in 3.19.
They have been written with the old ldapsource in mind, which has been dropped at
that time.

This behaviour was ok when we had "true" multi-sources but its rather painful
with datafeed sources. Also, it makes absolute_url() costlier than what it
should. Besides, it relies on cw_metainformation()['source'] that is pending for
removal.

Instead, add a link to the original object in the metadata view (the one that
displays eid and source at the bottom right corner of the primary view).

Related to #15538288.

This should be handled by specific parser to avoid using "entities.asource".
Reimplement it in the ldap parser.

Related to #15538288

This was clumsy and could be handled using exturi / cwsource, as the ldap source
now does.

This will break cwxmlparser based sources. They should be rewritten using a
specific parser, based on xml representation or on rqlio. This is harsh but
allows a so big cleanup of the code base.

Furthermore, it's necessary for asource/extid handling in the entities table
which is costly for most app that don't care at all about that...

In this cset, delete:

* all extid2eid methods
* repo._extid_cache handling
* [before/after]_entity_insertion source callback
* the cwxmlparser

and update related tests, notably unittest_datafeed where 'repull' testing has
been removed, since it's now handled by the dataimport API and should not be
retested there.

Related to #15538288

Closes #15538383

We may used cwuri for the same purpose, and do one more step towards deletion of
entities.extid column.

Related to #15538288

Apparently we are using some constants that got dropped/moved in ldap3 >=
2.0.0 (which came out last week). So stay with version 1.4 until this gets
sorted out.

in Python, 2.7, setuptools.command.develop.develop is an old style class, thus
it cannot be called with super.

The package may not be available in all systems (e.g. no Debian package exist
at the moment), and we should not crash with ImportError when importing
testlib from client code. Follow up on a6dc650bc230 where the dependency was
introduced.

this was used in the pre-datafeed area, it's not worth it anymore.

Its only valid usage was in authentication to detect if the source was
supporting CWUser, hence we now call it systematically and catch
NotImplementedError.

This is useful to do some import tests where you only want to test steps prior
to the database insertion, as well as "dry-run" commands.

Use it as a documenting base class.

with previous implementation, the original exception wasn't visible in python 2.

These are already site-packages along with cubicweb package.

The bare RuntimeError that gets emitted upon timeout does not help much to
diagnose the problem. Let's see if we can get more information from stdout by
not dropping it.

So that stop() method always gets called.

Also ensure temporary directory created on __init__ gets deleted as well upon
exit.

logilab-common's with_tempdir decorator, which is considered harmful (see
https://www.logilab.org/ticket/8267966).

Rely on backports.tempfile to provide TemporaryDirectory on Python 2.
Re-export it in testlib module for convenience.

The RelationField appends data to "pending_others" key while processing its
posted information, but this key may already have been removed by the edit
controller. So remove the key from session data only when all "others"
relations have been processed using a while loop.

A test case would be nice, but I could not build one easily unfortunately.

Closes #4354551.

It happens that if the parser could not be found, _pull_data() would just
return an empty dict without taking care to close the import log which it just
opened. This leads to misleading information in the user interface where
CWDataImport entities kept accumulating in the "imports" tab of CWSource
primary view without anything else happening.

So:

* log an error message when parser cannot be found
* always close (write logs and set "end_timestamp" attribute) import log when
  leaving _pull_data().

Closes #15505460.

This value means "all IP addresses on this host", which seems to fit with
"default to everywhere" that's documented.

Closes #15135610.

I do not understand why this assertion was there in the first place. And
currently, it makes running any migration impossible. Hopefully, someone may
be able to explain.

See also commit b48020a80dc3 which mentions this assertion and suggests to
remove it.

Not sure we can do better than a warning, which is better than nothing
anyways.

Closes #15785635.

This cleans up output of setup.py executions.

closes #15613724