#936 Feature: rpc api returns relative paths
Opened 7 years ago by mikem. Modified 6 years ago

What

When an rpc call returns data that corresponds to a file location (e.g. builds, rpms, archives, repos, ...), it should include a field that gives the path relative to /mnt/koji (or whatever topdir is).

Why

Generating the paths to content is sometimes a pain point with Koji. Python tools can use koji.PathInfo (though using it requires a little knowledge), but non-python tools have to generate their own.

Not every system will have the same topdir, but within that topdir, every system should have the same relative paths -- hence their use here.

With this data, clients could trivially combine the returned relative path with their topdir or topurl in order to access the content.

Examples

A hypothetical call to getBuild might would return something like:

{'build_id': 337,
 'nvr': 'fake-1.0-23',
 'name': 'fake',
 'version': '1.0',
 'release': '23',
 'volume_id': 1,
 'volume_name': 'test',
 'path': 'vol/test/packages/fake/1.0/23',
 ...
}

A hypothetical call to getRPM would return something like:

{
 'id': 926,
 'build_id': 337,
 'name': 'fake',
 'version': '1.0',
 'release': '23',
 'arch': 'noarch',
 'path': 'vol/test/packages/fake/1.0/23/noarch/fake-1.0-23.noarch.rpm',
 ...
}

Opened for discussion. Please give feedback.

(Please do not put significant work into this until it has been discussed and planned)

I like the idea. One concern, though, is that it doesn't include the path to any signed RPMs. So, it may not be as helpful for certain use cases. But, if signatures aren't needed, this definitely simplifies the end user code.

bikeshedding... maybe call it relative_path instead of path.

Related to #934
Is it better to have an option also to check the existence of the relpath on volumes?
Or a new hub call to do that?

Maybe it can be another call instead of adjusting current api?
Like getPaths()
<builds>
<build>
<id>123</id>
<files>
<file>nvra1.suffix<file>
<file>nvra2.suffix<file>
</files>
</id>
</build>
<build>
<id>345</id>
<files>
<file>nvra1.suffix<file>
<file>nvra2.suffix<file>
</files>
</id>
</build>
</builds>

Like that, it will be more easy to smuggle some request options.

Log in to comment on this ticket.

Metadata