Hey @dan-brown_0128,

And of course, the other issue with using SHA Digests is that they are unsortable/unordered, and there's no way to know if you're on an "newer" or "older" version. Git inherently has this same problem -- and users who try to name packages after commit hashes quickly learn how poorly that works :)

Looking around, it does look like some registries actually support immutable tags (Ex ECR, Harbor). Some tags make sense to be excluded from immutability - like latest since those are dynamic by intention.

ProGet's tags are effectively immutable -- in that you need the overwrite permission. But we also have the Semantic Container Versioning, which takes it a step further and enforces tags. Unfortunately, a lot of users don't use this feature or follow our guidance - and they end up with all the predictable headaches.

As an engineer, I'm obviously offended in principle by these bad practices, but more practically... the consequences of this kind of misuse/abuse is Tool Blame. And that means we look bad and don't get a renewal.

So, my philosophy/approach as a product vendor is "provide a good solution", not necessary "enough rope to hang yourself". As I mentioned before, OCI Repositories are poorly-designed solution to a misunderstood problem -- and my read is that it's going to be a passing fad.

Cheers,

Alex

Hey @davidroberts63,

Sure - let me elaborate on that.

A key tenet of software versioning is that a "version" represents a single, static/fixed revision of software - like there is only one "MyProduct 4.2.8", and no matter where/when you download that version, it's always the same thing.

OCI/Docker repositories do not have versions. It's just not a concept in the model, period. Instead, container images are "tagged," and it is up to the publisher to determine which container images have which tags and when those tags change.

This is all by design, and there's nothing inherently "wrong" with updating "MyProduct:4.2.8" until it's the right "version" of the container. If you want a "specific version of a version" you need to use the that utterly useless digest code. That's how these repositories are designed and used.

Compare this to package repositories, which are write-once by design and deletes are exceptional. This holds to the "a version is a static/fixed revision" principle.

ProGet does have the Semantic Versioning for Containers but it's not very popular, because it doesn't follow industry norm and developers want more control and customization over this.

Replacing/overwriting tags is the norm in a lot of container-based workflows, which causes all the problems you would expect.

All this is to say, I just can't see how OCI registries for generic artifacts are anything more than a poorly-designed solution in search of a misunderstood problem.

Cheers,
Alex

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.

Hey Michal,

Check out latest pgutil (2.1.7) - I just made a quick change and now Asset will work.

Also, so will Maven2.

Best,
Alex

hi @jacob-kemme_1710 , thanks for all of the details.

I'm pretty sure the Docker feeds already support OCI containers. They are basically identical from an API standpoint, and we've made a few tweaks here and there to accept different media types or parse a field in a manifest differently.

I know for sure that vnd.oci.image.manifest.v1+json is already supported.. and if there's something missing, it should be trivial to add. I'd post that as a separate feature request, since it's likely a basic tweak.

As for Helm... that's a different story. I don't think it's going to work, and it doesn't seem like a good fit for ProGet. Nor is a "generic OCI registry", which is why I'm hesitant to even consider the feature.

The main issue I have is that an OCI registry is tied to a hostname, not to a URL. This is not what users expect or want with ProGet -- we have feeds. Users want to proxy public content, promotion content across feeds, etc. None of this is possible in an OCI registry.

We got Docker working as a feed by "hijacking" the repository namespace to contain a feed name. Helm charts don't have namespaces, so this is a no go.

We got Terraform feeds working by requiring some stupid prefix on the module name. There's just no other way to do it.

I don't think that would be smart to do with Helm. And obviously we couldn't do that for "generic OCI" content since it's just meaningless blobs/binaries.

I'm open to learning more... but my initial take is that if users don't find values in "feeds" (well-defined content types, permissions, segmentation, replication, etc), and just want a "generic place to shove random content stuff" then ProGet isn't the tool?

Alex

@dan-brown_0128 thanks for clarifying

2500 is a lot more than I'm thinking... I was envisioning a handful of frequently-updated / highly-trusted packages (like AWSSDK, ). I think the UI would struggle a bit.

Thinking about this further... a blanket "all future versions are OK" policy seems like it will cause more problems than benefits. That's a lot of decision-making burden to shift to developers, and they're just going to hit "update" the moment they're prompted.

Best case scenario, that update delivers Zero Business Value... but there's a chance it'll introduce a regression, etc. I'd really need to study the data before recommending a practice like this (let adding a supported usecase for it) I'd be open to some sort of "automatic approval" feature, but I'd want to see some other factors in there, other than just "name matches X".

As it stands, "package approval/promotion" isn't very widely used as it's solving a problem most organizations don't believe they have. Instead they drop $300K+ for Clownstrike or another security tool and believe it just "does everything for them". At that price, how could it not!

So I think it's best to pin this for a bit. It's still a pretty "frontier" discussion/feature, and I don't want to "invent" something that's not going to get a lot of widespread use.

Hi @dan-brown_0128, @scampbell_8969,

We were reviewing this as part of our ProGet 2025+ roadmap, but I'm not sure if it makes sense to do. To summarize...

"Once a package has been approved (at a name level), all subsequent versions are OK assuming there's no vulnerabilities or license issues. However, the current promotion model requires that we promote each and every version. By automating version promotion, it would allow developers access to newer versions of packages sooner, making access easier and devs will be more likely to upgrade."

What about just using a connector with package filters in this case? For example:

1. Create feed nuget-unapproved, nuget-approved
2. Restrict promotion from nuget-unapproved -> nuget-approved
3. Create connector NuGet.org-all and associate with nuget-unapproved
4. Create connector NuGet.org-approved and associate with nuget-approved
5. Edit connector filters on NuGet.org-approved to block everything except packages you want

This would be possible today and would avoid adding a complex feature

Thanks,
Alex

Thanks @steviecoaster! All that sounds great, especially since it won't require changing anything on our end :)

Much appreciateD!!

@steviecoaster great thanks! That sounds good to me, I think having a new install option would be great.

Aside from supporting the package (which I'm not really worried about since you built it!!), the main concern I would have is keeping up with versions. We have frequent ProGet releases and pgutil is basically on demand.

I vaguely remember there was some kind of auto-packaging thing? Or maybe I'm dreaming that?

We could add something to our deployment plan that "does something" as well.

Hi @steviecoaster ,

That's awesome! I just added steviecoaster as a maintainer of the package, and it says pending approval.

Quasi-related, but I delisted all versions of romp and upack since we no longer publish/support those tools, but they are still showing up: https://community.chocolatey.org/profiles/inedo

Not sure if it takes time to reindex or whatnot?

Cheers,
Alex

Hi @mikes_4196 ,

Per the discussion above... can you tell me a bit about "we" (i.e. the size/profile of your organization) and describe how you are using winget in your organization? And why did you use WinGet instead of Chocolatey?

Per the discussion above, it does not look like a tool/ecosystem that is usable at scale. I get that it's built in to Windows, but I haven't seen a case study demonstrating a real deployment -- even within teams at Microsoft.

The "central repository" is just a giant mess of files in a GitHub repository and can't reasonably be "proxied" via a connector like other feeds. They apparently have "private repositories", but there's no documentation/guidance on how to create/use private packages for end users, so I don't think many are doing this.

But open to learning more.

Cheers,
Alex

@forbzie22_0253,

From an API standpoint, I believe only npm packages support server-side tags. Rubygems might, but in any case we strongly advise against using them: https://blog.inedo.com/npm/smarter-npm-versioning-with-semver/

Server-side tagging is not likely something we will support in the future. Deprecation and Listing are really only there because many of the client APIs support them.

I'd need to see a strong, specific use case. If it's related to quality (e.g. dev, staging, prod), then it's a "hard no" because our solution to quality is prerelease version numbering/tagging with repackaging.

I do know that Sonatype Nexus has always supported tagging, but their repository is more of a "fileserver with server-side metadata" and ProGet is package-based. The only documented use case they have for tags has been quality, and our solution/approach is far superior.

Cheers,
Alex

Hi @kichikawa_2913 @jeff-miles_5073 @martin-helgesen_8100 ,

Good news! We've got a Terraform Feed working on version 2024.20-rc.4 and it seems ready for release:

I'd love to get a second set of eyes on our approach and the docs; this was a really interesting protocol/API to work with because there are no "Terraform Packages" - basically everything is just a pointer to a GitHub repository.

So, ProGet just packages it in a universal package and the Terraform CLI seems to be happy. What's a little unfortunate is that the hostname/feed need to be in the package, but that's also how Docker works. So I guess it can't be helped.

Thanks,
Alex

Hi @zs-dahe ,

The Package Promotion API only be checks for permission against toFeed - you don't need any other permission on the toFeed or fromFeed.

As far as more granular permissions, perhaps setting up a Personal Key for like a builds user would do the trick? That'll let you reuse the API Key and set up very granular permissions.

We decided not to duplicate that granular permission setting in the API Keys because it's already confusing enough

Thanks,
Alex

Thanks for clarifying @matt-lowe!

some IT managers are very much stuck on the 'Microsoft' rut and are unable to see past it, no matter the cost and time it adds to most IT management
...
TBH the only way I managed to get ProGet installed was for managing PowerShell scripts for a small project and have managed to keep it ticking over with other options.

I've definitely heard that... personally I think this is where vendor/sales can really come in and make a difference.

Sometimes it's a lot harder to sell things internally... it's not so much about "giving a sales pitch" but more that decision makers can have a different relationship with sales execs.

It's one thing to blow off a vendor demo or delay a project... but team morale can get shot if you do that internally, so it's safer to stick to status quo. And of course, sales execs can challenge the status quo in a much more direct way... trying that as an employee might be uncomfortable or feel insubordinate.

Anyway this isn't related to WinGet, but we might be able to help with the bigger picture -- might be worth spending 15-20 minutes just talking through it and seeing if there's any paths to go from there. We're seeing a lot of movement on the WinOps/ProGet/Chocolatey in big orgs, so clearly they're getting something over DIY solutions or WinGet.

Feel free to shoot a note at the contact form, and we'll take it from there!

Hi @matt-lowe

You're the first person to ask about it in three years. I kinda forget it's a thing :)

So since then, feeds are a lot easier to build.. but I also don't want to implement the next Bower feed

I don't remember much interest in WinGet from our WinOps userbase... and I only occasionally see mention of it on Twitter𝕏. I think Chocolatey has a lot more traction and I get the impression that it's more capable, stable, and mature. And it's very well supported.

What's your impression? Have you been using it? What's better about WinGet over Chocolatey?

I think this somewhat recent Reddit comment captures the general sentiments about Microsoft projects like WinGet:

AFAIK, winget was/is a Microsoft led attempt to offer something instead of everyone using chocolately. Sadly though, it's not a replacement.
 
That is, Microsoft has an "answer", but not necessarily commitment behind winget. So, unknown how well packages sitting behind winget will be maintained. And historically, it has been under scrutiny. Is it good now? Not sure anyone can ever say for sure.
 
Now, there will be those that say "fixed", today's winget isn't like the absolute mess it was early on. And that might be true. But how would we (the customer) know? Again, biggest problem with Microsoft is the "not knowing". Or the "deception" of making a project look "better" and then realizing it was all just a ruse.
 
Up to you. Today's weather report, winget is "good". But can't really say anything about tomorrow. Oh, and thank you Microsoft for making yet another ambiguous thing (not handling its delivery, deployment or long term outlook well).

The fact that their package repository is just stupidly large GitHub repo maintained with pull requests is concerning. The discussion with @sylvain-martel_3976 above - I think they were just considering WinGet, and didn't use it yet. Not sure what ever happened with that.

Anyway let me know your thoughts!

Alex

@davidroberts63 check out 2024.14... added via PG-2783 :)

Also, on the builds page, I'd recommend having a sort and/or filter ability for the Stage.

Oh yes, I could see that helping... actually i'm not sure if it's even listed on the Build page. How many active builds do you have BTW?

@carl-westman_8110 very happy to hear it, thanks for the kind words :)

@carl-westman_8110 it's definitely a nifty and convenient function, but a poor feature from a product standpoint.

Users don't expect functionality to bundle content like this, so they won't use it unless we push it -- and to do that, we need to articulate benefits, show how it's a better solution than what they're doing now, and convince them to take the time to switch.

That's obviously a lot of work, on top of all the code to get it working.

I know a handful of users have found some value in virtual packages (and we use it internally), but being reminded about them now -- with about a decade more of experience behind me -- it feels like the wrong thing to focus on at the time, with limited resources.

That said, it doesn't even come close my top 10 worst product choices... so probably better we built that, than something else

Alex

Hi @carl-westman_8110 ,

It's a Virtual Package; they're kind of a niche solution that, in retrospect, we probably shouldn't have created them.

Alex