Thanks everyone for your interest in this. As @apxltd said, I'll be leading the effort on this. As the package format and repository system both seem relatively simple, I don't foresee too many technical challenges with adding this to ProGet, but there are a few things I'd like to make sure I understand right now:

1. ProGet typically needs to understand versioning rules for packages (to show which is the latest, to do retention policies, etc). From what I've gathered, CRAN uses 2 or more integers separated by dots. Does anyone know if that's required universally, or if it's just a convention?
2. CRAN doesn't appear to have a server-side repository API, instead just exposing a list of packages using HTML. Is my understanding correct here?
3. Submitting a package to CRAN looks like it's only done manually using a form here. Is that right, or is there some other automated mechanism that is used?

Also- we don't have any in-house R experts, so any (tentative) commitments to try out a prerelease version of ProGet with CRAN support would be very helpful in getting this feature out sooner :)

Thanks!

Hi Dennis,

Thanks for the feedback! You should be able to delete files/folders using the Asset Directory Delete API. Using curl, it should look something like this:

curl -X POST http://proget/endpoints/<AssetDirName>/delete/<path to directory>

We are actually focusing on Asset Directory improvements for the upcoming ProGet v6.0 release, so if you see any gaps or problems be sure to let us know!

-Greg

We've now reproduced this, and it turns out there's a regression in 5.2.13 with how config files are read which determine whether to use SQL Server or postgres. We have implemented a fix as PG-1614, which will be included in ProGet 5.2.14 (scheduled for release on Friday, October 18).

For now, I'd recommend just reverting to 5.2.12 until the next version is available.

Thanks to all who reported this!

Hi @pbinnell_2355,

Looks like the example code was incorrect. I've updated it. When a dotnet tool is installed globally, you run it by just running the tool name directly, so pgutil instead of dotnet pgutil

Hope this help!
-Greg

Sure. I've logged that change as PG-2508. It should be easy enough to make that URL configurable in ProGet.

Hi @itops_6398,

Thank you for the bug report. I've logged this as PG-2507, and we will likely have it fixed for the next release of ProGet 2023.20, scheduled for October 13. If the fix or testing turns out to be more than expected, it may get deferred to the following release, but I don't expect that to be the case here.

Hi,

Thanks for the bug report! We've logged and fixed these as PG-2098 and PG-2099. Note that due to limitations in how that dependency table is built, it's nontrivial to have it take you to the latest package that satisfies the given range if it has an exclusive upper bound - but we have changed it to prefer linking to the upper version number if one is present.

-Greg

Hi @Scati

Working with package qualifiers and purls is a little confusing with the API because they are already in a URL encoded query string format and you have to encode them again to be passed in through the API url. If you url encode what you are passing in to purl= then it should work:

https://serverip/api/packages/unstable-lin/delete?purl=pkg%3Adeb%2Fscatinat%407.2.2.0-1%3Farch%3Damd64%26component%3Dscati%26distro%3Djammy

The complexity of dealing with these is the reason we added all of the extra arguments and handling in pgutil to build these qualifiers out more easily.

Hope this helps!
-Greg

Hi Caterina,

pgutil does have the capability to do this if you use the builds sbom command. Apparently this command is hidden from the command list for some reason, but if you run pgutil builds sbom --help it should still show the options for it.

Does this help?
-Greg

Thanks @russell_8876! I've gone ahead and released pgutil 1.1.6 with a fix for this. Give it a try and let us know if it's still not working.

-Greg

Hi @caterina,

You are not overlooking anything, but we did :). We're still in the process of finalizing the commandsets for builds and projects - what we have in there now is something of a placeholder. I'll make sure we get that flag in the finalized version. We plan to have them done by early next week at the latest.

Thanks!
-Greg

Hi @Darren-Gipson_6156,

It looks like we hadn't published the latest version of inedoxpack to nuget.org. I've now published it manually, so if you run dotnet tool update inedo.extensionpackager, it should update to v1.0.7, which will be able to build the extension.

Sorry about that!

Hi @daniel-scati,

I've logged (and fixed) the duplicate versions issue as PG-2686, and that will be included in today's release (ProGet 2024.4).

Regarding the delete command, I've gotten it working using this command:

pgutil packages delete --source=scati --feed=stable --package="pacomalarmprocessor" --version=7.2.1.0-1 --qualifier="arch=amd64&component=scati&distro=bionic"

The only change I made was to put in the full version string instead of just 7.2.1.

Agreed on it being confusing that it succeeds even if the package wasn't found. That was one of those things that made sense in specification (why should I care if the package I want to delete doesn't exist?) but in practice it just hides an error. I think we'll eventually change this API to return an indication that something was actually deleted.

Hope this helps!

Hi @philippe-camelio_3885,

I've tried to reproduce this and I think the issue is that your variable is using JSON array notation instead of otterscript. So, it should be:

@(%(Nom:"Carbon",Version:"2.15.1"),...

It seems to work for me when I format it that way. Does this help?

Hi @artur-wisniowski_4029,

We'll get this fixed, but it's unlikely to be in this week's release. ProGet hashs the complete package file for every package uploaded to it, while the APK spec says to hash only over a certain tar segment of the package. We've been returning ProGet's hash of the package file as the checksum and this is incorrect as you've noted.

We'll post here again when we have a fix date, but I'd expect it will be either next week or the week after.

Thanks!

Hi @pbinnell_2355,

Looks like the example code was incorrect. I've updated it. When a dotnet tool is installed globally, you run it by just running the tool name directly, so pgutil instead of dotnet pgutil

Hope this help!
-Greg

Great to hear! Thanks for the followup