Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client refactor: directories and naming #1397

Closed
sechkova opened this issue May 18, 2021 · 4 comments
Closed

Client refactor: directories and naming #1397

sechkova opened this issue May 18, 2021 · 4 comments
Labels
experimental-client Items related to the development of a new client (see milestone/8 and theexperimental-client branch)

Comments

@sechkova
Copy link
Contributor

Move the packages under the client directory in a way that makes it easy to distinguish repository components from internal client components and client public API.

Proper naming is needed for the client refactor directory which is planned to land in the main branch in parallel with the current client.

@sechkova sechkova added the experimental-client Items related to the development of a new client (see milestone/8 and theexperimental-client branch) label May 18, 2021
@sechkova sechkova added this to the Experimental client milestone May 18, 2021
@jku
Copy link
Member

jku commented May 18, 2021

Background for these decisions is that we want the new client to co-exist with old one (tuf.client.updater.Updater) so need to think of clever naming.

There are three decisions that have not been made:

  • Module (& directory) name. Currently it's client_rework which is not great. Something short and recognizably client-related would be good. "client-ng" is boring but fits the requirements: other options are very welcome.
  • Public class (& file) name. Currently it's Updater which is the same class name as the old/current Updater... I think I'm fine with keeping it that but the downside is that the API is different and there's some possibility of confusion.
  • How to separate public/private API:
    • In any case I think we want to expose the public classes from __init__.py in client dir: this might be enough (only what's in the module itself is public, any submodules are not?)
    • Additionally we may want to put files that are clearly non-public into a _internal/ directory under client directory

So a model proposal based on those:

tuf/
    client-ng/
        __init__.py
        updater.py
        fetcherinterface.py
        _internal/
            requestsfetcher.py
            download.py
            metadatabundle.py

This is likely to not be final (in that I think there's probably functionality still in updater.py that could be separated out) but would be close enough for merging to develop

@jku
Copy link
Member

jku commented May 19, 2021

While we do this we should update tox config, and make it so the directory is omitted from coverage for now
python -m coverage report -m --fail-under 97 --omit "{toxinidir}/tuf/client_rework/*

@sechkova
Copy link
Contributor Author

sechkova commented May 20, 2021

#1401 implements a structure based on this proposal but also slightly different in terms of internal classes.

@sechkova
Copy link
Contributor Author

Closed with #1401.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
experimental-client Items related to the development of a new client (see milestone/8 and theexperimental-client branch)
Projects
None yet
Development

No branches or pull requests

2 participants