-
Notifications
You must be signed in to change notification settings - Fork 275
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
Comments
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]>
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 detailsCurrent source code (and upcoming 1.0 release) only contains the modern components
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. |
TUF provides interfaces for the update-providing side:
repository_tool
anddeveloper_tool
, and interfaces for the update-client side:updater
(and nowclient
...).On the update-providing side,
repository_tool
anddeveloper_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.The text was updated successfully, but these errors were encountered: