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

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 @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.

That's a display issue in pgutil. It's not supposed to show the build number as part of the version at all, so we'll fix that. Note that we do include the build as part of the tag, but the actual release title on GitHub is just 2.1.1, 2.0.6, etc. Thanks for reporting this!

Hi @layfield_8963,

Looks like this was just a simple bug preventing output from being written when stdout has been redirected. It's now fixed in pgutil 2.1.1.

Thanks for the update!
-Greg

Hi @dimas,

I've looked into this and it appears that restricted and multiverse in noble-backports do not actually have any packages in their indexes. It's a quirk of how these connectors are implemented in ProGet that components with no packages indexed are omitted from the output index. Is this causing a problem for you? We can look into changing this behavior, but it likely won't be a trivial fix.

-Greg

Hi @geraldizo_0690,

We've reproduced this and have a fix in internal testing as PG-3225. An incorrect index is causing the local connector database index to grow much larger than it should, and this effect is compounded in frequently updated repos like Kali.

We are currently testing the fix internally and will have it included in Friday's release of ProGet 2025.22. If you'd like to test the fix yourself soon, I can make a prerelease image available to you.

Thanks!
-Greg

Hi @brandon_owensby_2976,

Yes, that actually does wire things up with OtterScript, though I just realized I forgot to include a sample for how to actually invoke that script from OtterScript...

PSCall2 MyScript.ps1
(
    Parameters: %(inputvalue: Hello, resultingtext: outputvar)
);

Log-Information MyScript returned $outputvar;

The Parameters argument is meant to handle anything declared as an input/output value in the script's header. Note that for outputs you actually supply the name of the OtterScript variable to assign as the parameter value. For the record, I agree that this is all very confusing and we could certainly do a better job in the UI and docs. I believe the original goal when we added PSCall2 was to make the script parameters more discoverable, but at least as it works now, it has had the opposite effect.

That crazy stuff with the prefix is the mechanism it uses behind the scenes to capture output values that are declared in that parameters header or in the OuputVariables argument.

Does using this kind of header and PSCall2 invocation work at all for you? There's other things that could go wrong with marshalling values to/from PowerShell, but this ought to at least get you outputs without having to jump through those extra hoops.

-Greg

Hi @brandon_owensby_2976,

You're right that this is not very intuitive, and there are some outstanding issues we intend to fix in BuildMaster 2026. Generally, the best way to get all of this wired up right now is to have an Augmented Help header in the PowerShell script like this:

<#
.SYNOPSIS
    Appends world.

.AHPARAMETER inputvalue
    Input string

.AHPARAMETER resultingtext(output)
    Will be set to the resulting text

#>

param ([string]$inputvalue, [ref]$resultingtext)

$resultingtext = $inputvalue + " world" 

The key here is the [ref] specifier in the param block and the (output) specifier in the .AHPARAMETER augmented help header above.

For scripts without a param/Augmented Help header, you should be able to use the InputVariables and OutputVariables parameters of PSCall2 instead.

This is unfortunately missing from the docs at the moment, but before getting that updated I'd like to see if we can streamline or improve this to make it more intuitive.

Does this help at all? We're happy to work with you to improve this before the 2026 release.

Thanks!
Greg

Hi @Nils-Nilsson,

We've released pgutil 2.4.0 that has the audit command, along with a couple new commands under containers for adding/deleting tags. Note that it requires APIs added in ProGet 2026.3 or later.

Give it a try and let us know what you think.
-Greg

Hi @appplat_4310,

It shouldn't be a problem to get this in today's release (2026.2). I've logged it as PG-3295.

-Greg

Hi @Ashley,

It turns out that we just weren't reading upload-time from the upstream json when using the simple API, so this was pretty trivial to fix and we'll certainly be able to include it in tomorrow's release. Here's the abbreviated result of a quick local test I did after making the fix (also after fixing the issue with the duplicated versions):

{
  "meta": {
    "api-version": "1.1"
  },
  "name": "psycopg",
  "versions": [
    "3.0b1",
    "3.0",
    "3.0.1",
    "3.0.2",
    "3.0.3",
    "3.0.4",
    "3.0.5",
    "3.0.6",
    "3.0.7",
    "3.0.8",
    "3.0.9",
    "3.0.10",
    "3.0.11",
    "3.0.12",
    "3.0.13",
    "3.0.14",
    "3.0.15",
    "3.0.16",
    "3.0.17",
    "3.0.18",
    "3.1",
    "3.1.1",
    "3.1.2",
    "3.1.3",
    "3.1.4",
    "3.1.5",
    "3.1.6",
    "3.1.7",
    "3.1.8",
    "3.1.9",
    "3.1.10",
    "3.1.11",
    "3.1.12",
    "3.1.13",
    "3.1.14",
    "3.1.15",
    "3.1.16",
    "3.1.17",
    "3.1.18",
    "3.1.19",
    "3.1.20",
    "3.2.0",
    "3.2.1",
    "3.2.2",
    "3.2.3",
    "3.2.4",
    "3.2.5",
    "3.2.6",
    "3.2.7",
    "3.2.8",
    "3.2.9",
    "3.2.10",
    "3.2.11",
    "3.2.12",
    "3.2.13",
    "3.3.0",
    "3.3.1",
    "3.3.2",
    "3.3.3",
    "3.3.4"
  ],
  "files": [
    {
      "filename": "psycopg-3.0b1-py3-none-any.whl",
      "url": "http://localhost:5000/pypi/snake/download/psycopg/3.0b1/psycopg-3.0b1-py3-none-any.whl",
      "requires-python": ">=3.6",
      "size": 131830,
      "upload-time": "2021-09-03T21:34:46.638478Z",
      "hashes": {
        "sha256": "fd510caaaa90aec11781c0581a8a03f847e35925db6de293404db87d625a44e8"
      }
    },
    {
      "filename": "psycopg-3.0b1.tar.gz",
      "url": "http://localhost:5000/pypi/snake/download/psycopg/3.0b1/psycopg-3.0b1.tar.gz",
      "requires-python": ">=3.6",
      "size": 108312,
      "upload-time": "2021-08-30T04:25:06.027667Z",
      "hashes": {
        "sha256": "90188a415f2132eabccfa58ae41330d3bfc1c5c410add4d6194e783521478189"
      }
    },
    {
      "filename": "psycopg-3.0-py3-none-any.whl",
      "url": "http://localhost:5000/pypi/snake/download/psycopg/3.0/psycopg-3.0-py3-none-any.whl",
      "requires-python": ">=3.6",
      "size": 140812,
      "upload-time": "2021-10-12T16:20:12.084578Z",
      "hashes": {
        "sha256": "65b9fb8838dae61040ad3e0cfc184d4ffd17f740ef4c0353d76050a6eb061a9c"
      }
    }
    //...SNIP
  ]
}

Offline installers are available here which you can use to upgrade these older versions:
https://my.inedo.com/downloads/installers

We've tracked this down to an issue with native symbol files indexed in a PostgreSQL database. It will be fixed by PG-3243 in ProGet 2025.24, scheduled for release tomorrow (20 March 2026).

Packages with affected symbol files should be re-uploaded to ProGet following this release to resolve the lookup issue.

You can test the fix from this prerelease image: proget.inedo.com/productimages/inedo/proget:25.0.22-ci.4

In this version, it will automatically recreate each of those databases the next time it needs an update, and after that you should no longer see this unbounded growth. Let us know if you're still seeing a problem!

Hi @geraldizo_0690,

We've reproduced this and have a fix in internal testing as PG-3225. An incorrect index is causing the local connector database index to grow much larger than it should, and this effect is compounded in frequently updated repos like Kali.

We are currently testing the fix internally and will have it included in Friday's release of ProGet 2025.22. If you'd like to test the fix yourself soon, I can make a prerelease image available to you.

Thanks!
-Greg

Hi @Sigve-opedal_6476,

I haven't been able to reproduce this in a Rocky 9 test environment. After setting up the feed and connector in ProGet I ran dnf install zabbix-sql-scripts, and then repeated the test a few times with different versions and variations on formatting the versions. I also tried with cached and uncached packages. I was able to get a 404 to happen one time, but it was due to the upstream repo returning a 404 at the correct URL - which then worked the next time it was tried.

Is this happening consistently for you?