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

repository_tool vs developer_tool: refactoring needed #840

Closed
awwad opened this issue Mar 26, 2019 · 1 comment
Closed

repository_tool vs developer_tool: refactoring needed #840

awwad opened this issue Mar 26, 2019 · 1 comment

Comments

@awwad
Copy link
Contributor

awwad commented Mar 26, 2019

TUF provides interfaces for the update-providing side: repository_tool and developer_tool, and interfaces for the update-client side: updater (and now client...).

On the update-providing side, repository_tool and developer_tool have a lot of code achieving the same or similar things distinctly. These are in need of refactoring, as the disparities make the whole difficult to read and keep in mind, and they sit in a reference implementation. (Note that, historically, part of the reason for the redundant code is that they were originally intended as two separate stand-alone clients.)

Now, I think, the missions for these two modules should be to provide a simple, flexible, and thin interface to a set of code that provides the majority of the common functionality -- preferably in repository_lib, but alternatively in some new module if that proves more appropriate.

  • developer_tool is meant to allow developers an interface to update/sign their artifacts and provide whatever is needed to a repository maintainer
  • repository_tool is meant to allow repository maintainers to manage the repository, including updates to top-level roles and integration of delegated roles.
lukpueh added a commit to lukpueh/tuf that referenced this issue Sep 18, 2019
Import some API functions from repository_lib and securesystemslib
directly into repository_tool and developer_tool, instead of
providing them via wrapper.

Also short-circuit some functions that used to point to
securesystemslib through repository_lib.

This reverts parts of 6f7ba76,
which introduced some of the wrappers to appease the linter.
Here we just disable that specific linter check (unused-import).

The advantage of importing over wrapping is:
- no duplication of hardcoded defaults for keyword arguments
- no duplication of docstrings
- less code --> easier maintenance

This should also pave the way for more serious refactoring
of the repository- and developer-tools:
theupdateframework#840

Signed-off-by: Lukas Puehringer <[email protected]>
@joshuagl joshuagl added this to the Refactor milestone Jul 7, 2020
@joshuagl joshuagl removed this from the Refactor milestone Sep 8, 2020
@joshuagl joshuagl removed the refactor label Sep 10, 2020
@jku
Copy link
Member

jku commented Feb 16, 2022

Closing this issue as it was filed against (what is now known as) the legacy codebase: issue seems to not be relevant anymore. Please re-open or file a new issue if you feel that the issue is revelant to current python-tuf.

We do not have replacements for the tools yet (and likely will never have direct replacements) so this issue is not useful. There are plans for new repository components: see e.g. https://github.com/theupdateframework/python-tuf/blob/develop/docs/repository-library-design.md

More details

Current source code (and upcoming 1.0 release) only contains the modern components

  • a low-level Metadata API (tuf.api) and
  • tuf.ngclient that implements the client workflow,

Legacy components (e.g. tuf.client, tuf.repository_tool, tuf.repository_lib as well as the repo and client scripts) are no longer included. See announcement and API reference for more details.

@jku jku closed this as completed Feb 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants