feat: add fetch-tags

[rchamarthy]

No description provided.

[mikemccracken]

nice, thanks! What do you think about making the fetch-tags just a flag instead of a separate action, so that ociv . can still be the default viewing action, and you don't need to remember ociv view ?

[rchamarthy]

nice, thanks! What do you think about making the fetch-tags just a flag instead of a separate action, so that ociv . can still be the default viewing action, and you don't need to remember ociv view ?

Ok let me make it so. the problem is its not just one flag. Its 3 flags, registry, prefixes and output. We can eliminate output to be default ONLY. But I think we need the other two. So let me make them flags.

[rchamarthy]

nice, thanks! What do you think about making the fetch-tags just a flag instead of a separate action, so that ociv . can still be the default viewing action, and you don't need to remember ociv view ?

Ok let me make it so. the problem is its not just one flag. Its 3 flags, registry, prefixes and output. We can eliminate output to be default ONLY. But I think we need the other two. So let me make them flags.

Done - Please review.

[mikemccracken]

just looked at the code in fetch - one thing that was good about the old python script is that it didn't fetch info for layers it already knew about - it read the known-layers file first and skipped any that were already there; this made updating a lot faster:

oci-viewer/get-published-layers.py

Line 33 in 2fe93ce

if f'{imagename}:{tag}' in existingImages:

if you want to add that later I'm fine with merging this, once we figure out the issue I raised separately with connection errors

[rchamarthy]

just looked at the code in fetch - one thing that was good about the old python script is that it didn't fetch info for layers it already knew about - it read the known-layers file first and skipped any that were already there; this made updating a lot faster:

oci-viewer/get-published-layers.py

Line 33 in 2fe93ce

if f'{imagename}:{tag}' in existingImages:

if you want to add that later I'm fine with merging this, once we figure out the issue I raised separately with connection errors

I thought about it. I think we should actually not use cache. Because of retagging. A tag can be changed to a new SHA as per the distro specification so I decided not to cache. Let me know if you think otherwise.

[mikemccracken]

I thought about it. I think we should actually not use cache. Because of retagging. A tag can be changed to a new SHA as per the distro specification so I decided not to cache. Let me know if you think otherwise.

OK. I liked having a cache because of how long it took to get hundreds of image hashes, for the set of layers we have, but I agree that correct but slow is probably better for the public use.

maybe for future work we can have this loading go in the background and update the UI when done

it looks like the code as is will still use the file in ~/.cache/ociv if it exists and you don't pass -r -p right? that's a decent workaround for previous users

Ideally this would only query the registry for the few hashes we see, as we see them, but that requires e.g. zot's search extensions.

[rchamarthy]

I thought about it. I think we should actually not use cache. Because of retagging. A tag can be changed to a new SHA as per the distro specification so I decided not to cache. Let me know if you think otherwise.

OK. I liked having a cache because of how long it took to get hundreds of image hashes, for the set of layers we have, but I agree that correct but slow is probably better for the public use.

maybe for future work we can have this loading go in the background and update the UI when done

it looks like the code as is will still use the file in ~/.cache/ociv if it exists and you don't pass -r -p right? that's a decent workaround for previous users

Ideally this would only query the registry for the few hashes we see, as we see them, but that requires e.g. zot's search extensions.

Yes. Thats what I thought. We cache and update as we start seeing drift or updates to the local repos. To make an improvement on perf, I added parallel processing. We can optimize that with persistent connections. For that, I need to look into the HTTP Client's caching capabilities.