Skip to content

Conversation

@Urist-McGit
Copy link
Collaborator

Add a new --resolver option to the download command. New choices for this option can be added with plugins. The plugin functionality is based on entry points.

This is marked as Draft since I consider a full example of a plugin necessary documentation, and for technical reason this has to live in a separate repository. Until the Siemens internal review process for open source publications is done I can not publish it, so we have to wait until then. Otherwise I consider this ready, except for the missing link to the plugin examples repository.

Copy link
Member

@fmoessbauer fmoessbauer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general this implementation is already pretty solid. Just some minor comments.

@fmoessbauer
Copy link
Member

+cc @chombourger

@Urist-McGit Urist-McGit force-pushed the feat/plugin branch 2 times, most recently from fcbc98d to 671bb9b Compare November 25, 2025 13:02
As a preparation for upcoming work untangle the logic surrounding the
upstream resolver. For this create a generic base class for resolving
and a generic remote file representation. Move logic related to the
snapshot mirror to the snapshot client module.

Also factor out the resolve logic itself: there is a base part which
handles caching of packages and one specific to the actual resolver.

Signed-off-by: Christoph Steiger <[email protected]>
With the refactored remote file structure it is not possible to derive
the target path directly from the remote file. For this information
about the package, namely if it is source or binary, is required.

The size is also optional now, so the calculation of download sizes
needs to consider that too. For files where the size is unknown the size
is 0.

Signed-off-by: Christoph Steiger <[email protected]>
With the --resolver option a resolver can be specified. As it stands
right now there is only one resolver for the debian snapshot mirror.

This option is intended to be used by plugins in the future.

Signed-off-by: Christoph Steiger <[email protected]>
We currently only have a simple file cache. Make it unique by adding the
resolver type to the cache directory.

Signed-off-by: Christoph Steiger <[email protected]>
Allow a cache implementation to be replaced while in use. This is
required so we do not have to pass the default cache instance to the
initialization.

This is in preparation for the upcoming plugin work. The use-case is to
allow for custom cache implementations and, in case no custom
implementation is provided, use our internal default implementation.

Signed-off-by: Christoph Steiger <[email protected]>
To decouple the caching implementation and the resolver it is necessary
to upcast any downstream RemoteFile to its base instance. Our simple
cache implementation otherwise stumbles over any additional fields that
might have been added to any downstream remote files. Our caching
implementation works solely based on the hash of the remote file, which
is already available in the base instance.

Signed-off-by: Christoph Steiger <[email protected]>
Introduce a common base error for resolving. This error is caught on the
outermost level instead of the snapshot error now.

Signed-off-by: Christoph Steiger <[email protected]>
Add the option to use plugins for resolving download location of
packages.

Signed-off-by: Christoph Steiger <[email protected]>
Since resolvers do not necessarily look "upstream", the error message is
now more general and simply states that the package could not be
resolved.

Signed-off-by: Christoph Steiger <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants