In D1478#32900, @vlorentz wrote:

wat?

rebased

In D1463#32651, @anlambert wrote:

Real word example of why using private members is a bad idea: https://github.com/Tulip-Dev/tulip/commit/cbb85d65da2cb262e0c20f2b9b16603b8a633aed#diff-675480f07686e76ad2b178ce3b9ccd4e

When Python 3.7 was released, some signatures in his private C API were updated.
We were using them to register internal Python modules written in C to an embedded interpreter (gdb did also the same, I found the proper fix from their mailing list) and thus compilation broke.

Ok this is a C example but the same could happen for Python code.

import CONTEXT_SETTINGS fron swh.core

rebased on D1478

cli: import CONTEXT_SETTINGS from swh.core

add support for --help on the 'identify' cli tool

Let someone else give the thumbs up/down

In D1463#32643, @douardda wrote:

In D1463#32623, @anlambert wrote:

I don't really understand why you did this. What is the problem with the current implementation. Sure it uses a 'private' API, but the logging module won't change any time soon...

Maybe but this is a bad practice and should be avoided.

<slightly_bad_faith_ mode>like keeping a hand written copy of a piece of data that is in fact defined somewhere else </>

In D1463#32623, @anlambert wrote:

I don't really understand why you did this. What is the problem with the current implementation. Sure it uses a 'private' API, but the logging module won't change any time soon...

Maybe but this is a bad practice and should be avoided.

I would have just written this as

setup_log_handler(
    loglevel=ctx.obj.get('log_level', logging.INFO), colorize=False,
    format='[%(levelname)s] %(name)s -- %(message)s',
    log_console=not no_stdout)

but meh

In D1463#32599, @anlambert wrote:

Update:

• cli: Remove use of private members from the logging module

LGTM but I did not do a very punctilious review

I agree it's easier to read, so LGTM (just a small refactoring and I'm ok with this)

closed by b0fcdebc823fee02dd718c4526829476438daf6c

lgtm

In D1444#31990, @douardda wrote:

In D1444#31943, @vlorentz wrote:

Instead of swh/core/X/tests/, you should put tests in swh/core/tests/X/ (where X is the sub-component), for uniformity with other repos (deposit/indexer/storage/web)

let me check that

Add missing __init__.py files

In D1444#31943, @vlorentz wrote:

Instead of swh/core/X/tests/, you should put tests in swh/core/tests/X/ (where X is the sub-component), for uniformity with other repos (deposit/indexer/storage/web)

In D1444#31944, @ardumont wrote:

Build fails with:

_______________ ERROR collecting swh/core/db/tests/test_db.py _________________
swh/core/db/tests/test_db.py:14: in <module>
    from .db_testing import (
E   SystemError: Parent module '' not loaded, cannot perform relative import
!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!
=

Wondering if we are not missing __init__.py files in the new subfolders created (db, api, server)?

In D1445#31940, @ardumont wrote:

debian related, i'm wondering how to package this ;)

Not a big stuff, but I would have preferred to see the refactoring (of the get_local_backend's code) and the actual fix (add client_max_size arg when calling make_app) in 2 revisions.

This won't be done as a separate project, but rather from swh.core directly. see D1426

rebased + bump dep on swh.core 0.0.60

add missing \ and 's/^I/ /' as noticed by ardumont

rebase

depends on swh.core 0.0.60