Reviewed the code in-person with @frantisekz, there will be some cleanup done to this :D

@pingou I've added ELN Support here, so this is complete minus obsolete updates. They are not shown on pagure, do we need them?

Apart from that, how would you want to handle the configuration of oraculum url here?

Apart from that, how would you want to handle the configuration of oraculum url here?

Take it from pagure's config?

Apart from that, how would you want to handle the configuration of oraculum url here?

Take it from pagure's config?

Yeah, I should have figured that out, thanks! Filled https://pagure.io/pagure/pull-request/5149# for this and updated this PR.

I'll be deploying new oraculum build to production tomorrow, but if you really wanted to test this out, using ORACULUM_URL = "https://packager-dashboard.stg.fedoraproject.org/api/" should work already.

frantisekz commented on the pull-request: Fetch package versions from oraculum that you are following:
``

Apart from that, how would you want to handle the configuration of oraculum url here?

Take it from pagure's config?

Yeah, I should have figured that out, thanks! Filled https://pagure.io/pagure/pull-request/5149# for this and updated this PR.

It shouldn't be upstream, you can have it in the config without it being in the
default config.

IIRC we document some pagure-dist-git's specific configuration keys in the
README.

I'll be deploying new oraculum build to production tomorrow, but if you really
wanted to test this out, using ORACULUM_URL =
"https://packager-dashboard.stg.fedoraproject.org/api/" should work already.

roger, thanks!

It shouldn't be upstream, you can have it in the config without it being in the
default config.

IIRC we document some pagure-dist-git's specific configuration keys in the
README.

Oh, okay, would something like this be okay? Or shall I import pagure_config as it is in dist_git_auth.py?

Thanks!

FYI: changes in the backend are now deployed in production.

Just tested it and it works fine :)

My worry is introducing a dependency between oraculum and dist-git.

@kevin any thoughts on this?

Just tested it and it works fine :)

My worry is introducing a dependency between oraculum and dist-git.

@kevin any thoughts on this?

Thinking about this, if you're worried too much, I can leave the bodhi code in place too (or rather, move it into a separate function) and call it if/when oraculum fails to return meaningful data.

EDIT: I mean, it shouldn't happen, unless repo metadata format or bodhi api changes, relevant code around versions parsing is here, if you want to take a look: https://pagure.io/fedora-qa/oraculum/blob/master/f/oraculum/utils/versions.py and https://pagure.io/fedora-qa/oraculum/blob/master/f/oraculum/utils/bodhi.py .

Just tested it and it works fine :)

My worry is introducing a dependency between oraculum and dist-git.

@kevin any thoughts on this?

Thinking about this, if you're worried too much, I can leave the bodhi code in
place too (or rather, move it into a separate function) and call it if/when
oraculum fails to return meaningful data.

I have been thinking about this a bit as well. That'd be +1 for me!

I missed whats the advantage(s) here? Just faster/less load on bodhi? or ?

Faster and I think more correct data (and less load on bodhi and mdapi with the caching that oraculum has)

I missed whats the advantage(s) here? Just faster/less load on bodhi? or ?

Yeah, we're parsing version information from repo metadata and bodhi anyway and I thought pagure might make use of cached pakage-version pairs.

@pingou Added back bodhi as a fallback code (while few making adjustments so the returned data are consistent with what oraculum path returns - no obsolete updates and existing keys with None values for no data). This PR also includes https://pagure.io/pagure-dist-git/pull-request/137# for now (I expect you'll merge that one first, I'll rebase and squash this then).

If it's just that info sure... I wonder if the new packager-static couldn't be the source, but thats just adding more confusion/apps. :)

@frantisekz #137 has been merged, you can rebase this one :)

@frantisekz #137 has been merged, you can rebase this one :)

Rebased and squashed :)

Looks good to me!