Hello; I've updated the documentation to clarify this, but it's available starting in ProGet 5.2.9. So, you'll need to upgrade to enable it :)

Thanks for the update! I've noted this in the docs, and linked to this discussion :)

https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39

Hello,

That API will only delete package metadata from the database, not from disk. It's mostly intended for internal use only, and probably shouldn't be exposed to the API. In any case, we don't store the @ with internally, so if you change @myscope to myscope it should work.

Note that the NPM doesn't provide a way to delete packages, and we never implemented it. There hasn't been any demand for it to date, as people don't really delete packages programmatically - but you're definitely welcome to submit a feature request and help us understand why it'd be a value (like, the workflow you use that requires deleting packages, etc).

Alana

Hello, for sure!

It's pretty easy; just don't give the Anonymous user any access to your feeds, and then authentication will always be required, either when browsing the ProGet application or using the API (such as Install-Module).

When you use the Register-PSRepository command, you can the Credential option to specify a credential.

This credential can be the name/password of a user inside of ProGet (let's say, Admin:Admin), or it can be username of api with a password of an api key you've configured (so, api:my-secret-key).

Hello;

The Native API is for low, system-level functions, and it's "all or nothing". If you give someone access to Native API, you are effectively making them an administrator, as they can also change permissions and grant admin privileges. So, I don't think you want this. Instead, you'll want to use the Debian API endpoint that we implement.

It's a third-party API format

In order to support third-party package formats types like NuGet, npm, etc., ProGet implements a variety of third-party APIs. We only provide minimal documentation for these APIs, as they are generally either already documented elsewhere. However, you can generally find the basics by searching for specific things you'd like to do with the API, such as "how to search for packages using the NuGet API" or "how to publish an npm package using the API".

So in this case, I recommend to search "how to view and download apt packages".

I'm not very familiar with PyPi packages, but I know there are some oddities with - and _, and that they are sometimes supposed to be treated the same, and sometimes not. We don't totally understand all the rules, to be honest (even after reading PEP503 specifications).

In this case, the package is actually websocket_client, not websocket-client.

See: https://pypi.org/project/websocket_client/

When you search for websocket_client in ProGet, it shows up, as expected.

In ProGet 5.3, we plan to have a couple tabs on each Tag (i.e. container image) that would provide this info: Metadata (will be a key/value pair of a bunch of stuff), and Layers will show details about each of these layers.

That might help, but otherwise, we have retention policies which are designed to clean up old and unused images.We'll also have a way to detect which images are actually being used :)

As @apxltd mentioned, we've got a whole bunch planned for ProGet 5.3.

I've logged this to our internal project document, and if it's easy to implement in ProGet 5.2 (I can't imagine it wouldn't be), we'll log it as a bug and ship in a maintence release.

Do note, this is not an IMAGE description, it's a REPOSITORY (i.e. a collection of images with the same name, like MyCoolContainerApp) description; so this means the description will be there on all images/tags in the repository.

You're right, I guess that's showing the "layers" instead of the "tags"; I think it should be showing container registries separately (they're not really feeds), but that's how it's represented behind the scenes now.

Anyways we are working on ProGet 5.3 now; there's a whole bunch of container improvements coming, so I've noted this on our internal project document, to make sure we get a better display for container registries.

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

Thanks @wechselberg-nisboerge_3629 , Exactly what I was looking for!

Can you provide some more information about this image? Basically I'm trying to find the layer / mediatype / size. I believe these commands will do it:

docker image inspect vl-dev-repo.ki.lan/sst-coco-oci-prod/sub-coco-cli:test --format '{{json .RootFS.Layers}}' | jq .

docker history vl-dev-repo.ki.lan/sst-coco-oci-prod/sub-coco-cli:test

Thanks,
Alana

Hi @koksime-yap_5909 ,

[1] I would do localhost as to reduce network traffic; a lot of time, "loopback" connections are handled in software and never make it to the network hardware

[2] multiple copies of the package are stored

In general, you should use data-deduplication anyway. Even with out self-connectors, we've seen a 90% reduction in space due to the nature of what's stored (i.e. nearly identical versions).

Thanks,
Alana

@wechselberg-nisboerge_3629 the main thing I'm looking for is the HTTP access logs - we have 1.5 Entires before (PATCH-finish, PUT-Start, PUT-finish), so seeing more would be really helpful.

What's odd is seeing the "retrying..."

@wechselberg-nisboerge_3629 thanks for comfirming!

Any chance you can get more entries from the container log? It'd be really helpful to see more requests going back/forth. This is just such a strange behavior given the seeming simplicity of your image

Also, there should be an option, in ProGet 2025.12, to enable web logging (Admin > HTTPS Logging); it's a brand new feature, but it writes logs to a log file.

Hi @mayorovp_3701 ,

Thanks for confirming; we can will try to get this fixed in the next maintenance release via PG-3139 -- the underlying issue is most likely a race condition on that trigger I mentioned, so we're going to fix it by adding an advisory lock.

It will not remove the duplicate content, but in theory deleting the image will.

Thanks,
Alana

Hi @koksime-yap_5909 ,

I'm afraid this is a known limitation with Maven feeds; we made the assumption that package authors would follow the bare-minimum of Maven versioning: packages start with letters, versions start with numbers.

The only examples we found that were counter to that were 20+ year old artifacts, however, we've since learned that authors still mistakenly use these incorrect versions.

Unfortunately, supporting these types of versions require a complex/risky change.

Maven is a file-based API and the client just GETs/PUTs files. However, ProGet is not a file server so we need to actually parse the URLs to figure out which artifact/package the files refer to. In this case, we parse package-alpha-0.1 as package-alpha (version 0.1), not package (version alpha-0.1). Hence, why it's not working.

If these are your internal packages, the easiest solution is to follow the standard:
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm

Thanks,
Alana

Hi @wechselberg-nisboerge_3629 ,

This is definitely a strange error; are you using PostgreSQL by chance?

I'm seeing 53babe930602: Retrying... a few times. Is this consistently happening with this layer? Is there anything special about it (big, small, etc)?

Thanks,
Alana

@Sigve-opedal_6476 great news! Thanks for the update

Hi @pawel-ostrowski_5669,

Actually the version you're using (2025.8) has a known regression relating these PackageIds that we already fixed via PG-3097. I didn't realize it until you told me the version and I found that issue.

Anyway please try latest version of ProGet 2025, it should work.

Thanks,
Alana

Hi @parthu-reddy ,

I'm not sure what version you're using, but the latest version has a checkbox on the reindex function to delete duplicate ids/names wen running the reindex job.

I would try that -- note you may have to run it twice. This issue is fairly complicated and it's hard to fix without working against exported/backups of user databases.

Thanks,
Alana