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

@it_6176 thanks for sharing!

You're right, we did not consider this usecase when designing Debian connectors. Our "default mode" in ProGet is "dynamic indexes", but the quirkiness of the Debian repository "API" and obscene size of operating-system libraries make that impractical when there is a lot of feed activity (i.e. packages being added to the feed via caching).

We are going to redesign this at some point, and allow for some kind of "periodic indexing" for some connectors. That would be run as a job, as opposed to triggered by a user's request.

As for the database.... we've had one other user report that those SQLLite databases "blew up" as well, and our conclusion is that "something" crashed at the wrong time. Probably, due to the resource overusage? It has something to do with the WAL Files, but we're not totally sure.

I think we just need some kind of regular clean-up for these "huge" connectors so the database doesn't get so huge.

Hi @caterina ,

I agree and there doesn't seem to be any good usecases or official guidance from npm tags command, but we do not recommend using them: https://blog.inedo.com/npm/smarter-npm-versioning-with-semver/

From the api/technical standpoint, npm tags are a little weird -- a package themselves doesn't contain tags. Instead, the registry has a key/value tag store. By convention, the store has keys like latest and values like 4.8.1, but it seems to allow anything? At least from data we've seen on npmjs.org

In any case, the npm client seems to set a latest tag, so we'll just support that use case then.

FYI here is the logic/code I added:

        var tags = await this.GetPackageTagsAsync(purl.Name, false, cancellationToken: cancellationToken);
        if (tags.TryGetValue("latest", out var latestVersion) && latestVersion == PackageVersion<SemanticVersion2>.Parse(purl.Version))
            await DB.Npm_SetTagVersionAsync(toFeed.FeedId, purl.Name.Id, "latest", purl.Version, DateTime.UtcNow);

It sets the latest tag on the other feed if the current feed's latest tag points to the package you are promoting.

Thanks,
Alana

Hi @caterina ,

This behavior is expected as only the package itself is promoted, not repository metadata.

I'm not an npm developer, but one concern I have is that the latest tag doesn't always refer to the most recent version of a package? It's a little confusing to be honest, but I read that developers will sometimes use latest to "pin" what they feel is the most stable version?

I don't understand why this is a practice in npm, but I think this is probably an exception. So, we will change the behavior via PG-3057 such that the "latest" tag is set on the new feed when promoting latest-tagged npm package.

This will be in the next maintenance release of ProGet 2025.

Cheers,
Alana

Hi @phopkins_6694

Looks like this is a regression in ProGet 2025; we'll get it fixed in the next maintenance releaese, scheduled for this Friday via PG-3056

Cheers,
Alana

Hi @kc_2466 ,

Can you share how / why you're create Universal Packages in the UI? And perhaps how you're using upacks in general?

We added them as a way to introduce the format to new users, but didn't really anticipate it being used beyond that.

Thanks,
Alana

Hi @kc_2466 ,

We'll Add support for LC_TIME environment variable & user setting via PG-3054 in an upcoming maintenance release -- p[robably not this week's, but in the next or following.

Thanks,
Alana

Hi @carsten_1879 ,

We should have a build of BuildMaster 2025 later this week that you can try out that includes the new library. We'll let you know!

Thanks,
Alana

Hi @imm0rtalsupp0rt ,

Thanks - I was able to reproduce this issue. It's some long-standing behavior / bug, and not a trivial fix.

We will see about fixing it in the upcoming maintenance release (PG-3048), but it's lower priority and will likely get pushed back a few releases.

Cheers,

Alana

Nice idea! That was pretty trivial to add in there, and will be in the next maintenance release via PG-3038:

Hi @misael-esperanzate_5668 ,

I'm not really sure, but I'll explain how things work so it might help troubleshoot.

First, the Maven API does not provide a file listing. While you (as a user) can often "see" via an HTML page (like this listing at jboss.org), it's simply not available for listing in the API. The only required file in an artifact is the .pom file, so when you "pull" an artifact to ProGet, that's all you'll get.

Next, the "remote" icons next to the files indicate that they were cached (i.e. added to the feed) via a connector. That means the files were successfully written to disk, recorded in the database... but now they are gone. Hence, why you keep getting the "file not found" message.

The most likely culprit for this is something deleting the files from a packagestore. We often see security tools doing that for "safety" reasons, since they are .jar files that may be dangerous I guess.

Overall, the maven API is a very simple series of GETs. So perhaps, you can just experiment with this? First, start with a brand new feed and a connector.

Then, run the command:;

curl http://my.server.local:8624/maven2/my-new-feed/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar --output hamcrest-core-1.3.jar

You should see the file download via CURL. Afterwards, you should see the artifact as a cached package (Top Navigation > Packages > Select Cached). You should also see that .jar file on disk, written to the package store location (Manage Feed > Storage).

If you don't see a .jar file downloaded to that location on disk, then it means something is "blocking" the file being written. If it's there, then it means something is deleting it after.

Thanks,
Alana