Hi @dan-brown_0128,
Thanks for continuing the discussion.
From that quote, I get the sense that the container feeds were implemented by trying to force the process into what was implemented for traditional file-based packages rather than treating container images as a different style of artifact. This would explain why it seems OCI isn't a direct drop in fit -- because other traditional package consumers (pypi, nuget, maven, etc) do not behave the same as OCI.
Docker and Asset feeds are implemented considerably different than the other feeds, and even have a different UI/pages because of that. But the model of "feeds" and "proxying" (i.e. what people want to do with ProGet) is just fundamentally incompatible.
The OCI API is effectively identical to Docker API, but there's no sensible way to display/visualize "generic" artifacts. They have no name, just useless digest hashes. It'd be like using Git without comments, dates, or files names.
On the shock that for container images that you have to provide the URL to access the image -- that's not all that different than traditional software packages. Just on those traditional package tools you're specifying that URL Prefix as part of the client's configuration.
That's a pretty big deal IMO, and why this approach is dead in the water when dependencies are involved. It's a huge headache with Helm already - URL Prefixs need to change.
It's bad enough every single one of your build/deployment scripts need to be updated if you want to change the "URL Prefix" of a "source" (switching products, domain name changes, etc.) -- but these URL Prefixes are embedded in manifest/metadata files stored in the registry.
Of course, you can't "edit" those files stored in the registry, since the digest/hash would change, so you have to republish everything... which would cause anything that references those digests/hash to break.
If you've "transcended versioning" and always deploy the latest commit of everything always, then none of this really matters - but versioning is important for a lot of users still. Tags are not suitable for versioning.
Last one -- The URL thing. Take a look at some other common registries, including the public GitHub container registry. For those, the URL is always ghcr.io but they then prefix the image with the User/Org (eg: https://github.com/blakeblackshear/frigate/pkgs/container/frigate/394110795?tag=0.15.1). Truthfully, Proget could do a similar approach: proget.corp/MyOciOrDockerFeed/image/path/here:1.2.3
This is what ProGet has to do now -- we "hijack" the first part of the container namespace for the feed name, and GitHub does that same thing. But you're basically stuck forever with that host/feed name.
