Posts made by appplat_4310

Hi @gdivis , thanks for the quick turnaround.
Everything is working as expected with the new version.

Cheers

Following on from the recent PEP 700 work in PG-3272 / PG-3288 — we've hit a related but distinct issue with upload-time on ProGet 2026.1 (build 14).
The field is now present (good), but the fractional seconds are sometimes serialised to 2 digits, e.g. 2026-04-15T10:23:45.12Z. PEP 700
says the fractional part "may contain up to 6 digits of precision", so this is arguably spec-compliant, but it breaks every Python 3.10 client running pip ≥ 25.3.

The reason: pip 25.3+ reads upload-time on every resolve (for the --uploaded-prior-to feature) and parses it with datetime.fromisoformat. The pre-3.11 implementation of fromisoformat only accepts 0, 3, or 6 fractional digits — 2 digits raises ValueError. Python 3.11+ has the rewritten parser that handles arbitrary precision, so it doesn't reproduce there. PyPI itself always emits 6-digit microseconds, which is why this hasn't surfaced before.
The fix on ProGet's side should be a one-liner: pad/format fractional seconds to either 0, 3, or 6 digits (6 to match PyPI is probably safest).

Repro
Against a ProGet 2026 PyPI feed, with a package whose upload-time happens to truncate to 2 digits (we're seeing it on setup-rebalance):

uv venv repro --python 3.10            # gets default pip 23.0.1
repro\Scripts\python -m pip install --dry-run --no-deps ^
  --index-url https://<proget-host>/pypi/Python/simple ^
  --trusted-host <proget-host> setup-rebalance
# works (pip 23 doesn't read upload-time)

repro\Scripts\python -m pip install --upgrade pip   # -> pip 26.1.1
repro\Scripts\python -m pip install --dry-run --no-deps ^
  --index-url https://<proget-host>/pypi/Python/simple ^
  --trusted-host <proget-host> setup-rebalance
# fails on ValueError from datetime.fromisoformat

Confirming directly in Python 3.10:

>>> from datetime import datetime
>>> datetime.fromisoformat('2026-04-15T10:23:45.123456')  # OK
>>> datetime.fromisoformat('2026-04-15T10:23:45.123')     # OK
>>> datetime.fromisoformat('2026-04-15T10:23:45.12')      # ValueError

Impact
Anything running Python 3.10 with pip auto-upgraded (which is a common pattern — python -m pip install --upgrade pip is in lots of bootstrap scripts in the wild). Once pip ≥ 25.3 is installed, the env is bricked against any ProGet PyPI feed serving 2-digit fractional upload-time values.

Could you confirm whether this is in scope for a maintenance release? Happy to provide the raw JSON response from our feed if useful — just let me know where to send it.

Cheers

Hi,
we are having troubles connecting an internal feed to Telerik public feed, the aim is to locally cache packages and distribute them to the internal users.

We configured a new NuGet Feed and a new connector to Telerik using the endpoint they provide in their docs (https://nuget.telerik.com/v3/index.json) , with basic authentication using an API key of a user with a valid Telerik license (api-key as the username and the actual key as the password, as suggested by the Telerik).

We are now able to browse the Feed and we see the package list, versions, descriptions and so on but we are not able to download/cache any package.

If I try to manually trigget the download/pull of a specific version of a package I get this error:
Download:

Package file is missing.

Pull (setting https://nuget.telerik.com/v3/index.json as "NuGet Feed"):

The package could not be installed.
The package was not found on the remote repository.

Also we get this error logged when trying the Pull:

Connector Telerik error: Object reference not set to an instance of an object.

System.NullReferenceException: Object reference not set to an instance of an object.
at Inedo.ProGet.Feeds.NuGet.NuGetConnector.FindPackagesByIdAsync(NuGetQueryOptions options, String id)

Otherwise no errors are logged in the system, this is the output if I try to use the Proget feed with nuget.exe:

.\nuget.exe install Telerik.Windows.Controls.RibbonView.for.Wpf -Source https://nuget.my.domain/nuget/Telerik/v3/index.json -source https://nuget.ges.ferlan.it/nuget/Default/v3/index.json
Feeds used:
  https://nuget.ges.ferlan.it/nuget/Telerik/v3/index.json
  https://nuget.ges.ferlan.it/nuget/Default/v3/index.json
  https://api.nuget.org/v3/index.json

Installing package 'Telerik.Windows.Controls.RibbonView.for.Wpf' to 'C:\Users\myuser\NugetTest'.
  CACHE https://nuget.my.domain/nuget/Telerik/v3/registrations-gz/telerik.windows.controls.ribbonview.for.wpf/index.json
  GET https://api.nuget.org/v3/registration5-gz-semver2/telerik.windows.controls.ribbonview.for.wpf/index.json
  GET https://nuget.my.domain/nuget/Default/v3/registrations-gz/telerik.windows.controls.ribbonview.for.wpf/index.json
  NotFound https://api.nuget.org/v3/registration5-gz-semver2/telerik.windows.controls.ribbonview.for.wpf/index.json 646ms
  NotFound https://nuget.my.domain/nuget/Default/v3/registrations-gz/telerik.windows.controls.ribbonview.for.wpf/index.json 826ms


Attempting to gather dependency information for package 'Telerik.Windows.Controls.RibbonView.for.Wpf.2024.3.924' with respect to project 'C:\Users\myuser\NugetTest', targeting 'Any,Version=v0.0'
Gathering dependency information took 32.25 sec
Attempting to resolve dependencies for package 'Telerik.Windows.Controls.RibbonView.for.Wpf.2024.3.924' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Telerik.Windows.Controls.RibbonView.for.Wpf.2024.3.924'
Resolved actions to install package 'Telerik.Windows.Controls.RibbonView.for.Wpf.2024.3.924'
  GET https://nuget.my.domain/nuget/Telerik/v3/flatcontainer/Telerik.Windows.Controls.Input.for.Wpf/2024.3.924/Telerik.Windows.Controls.Input.for.Wpf.2024.3.924.nupkg
  GET https://nuget.my.domain/nuget/Telerik/v3/flatcontainer/Telerik.Windows.Controls.Navigation.for.Wpf/2024.3.924/Telerik.Windows.Controls.Navigation.for.Wpf.2024.3.924.nupkg
  GET https://nuget.my.domain/nuget/Telerik/v3/flatcontainer/Telerik.Windows.Controls.for.Wpf/2024.3.924/Telerik.Windows.Controls.for.Wpf.2024.3.924.nupkg
  GET https://nuget.my.domain/nuget/Telerik/v3/flatcontainer/Telerik.Windows.Data.for.Wpf/2024.3.924/Telerik.Windows.Data.for.Wpf.2024.3.924.nupkg
  NotFound https://nuget.my.domain/nuget/Telerik/v3/flatcontainer/Telerik.Windows.Controls.Navigation.for.Wpf/2024.3.924/Telerik.Windows.Controls.Navigation.for.Wpf.2024.3.924.nupkg 1015ms
  NotFound https://nuget.my.domain/nuget/Telerik/v3/flatcontainer/Telerik.Windows.Controls.Input.for.Wpf/2024.3.924/Telerik.Windows.Controls.Input.for.Wpf.2024.3.924.nupkg 1078ms
  GET https://nuget.my.domain/nuget/Telerik/v3/flatcontainer/Telerik.Windows.Controls.RibbonView.for.Wpf/2024.3.924/Telerik.Windows.Controls.RibbonView.for.Wpf.2024.3.924.nupkg
Found package 'System.Data.OleDb 7.0.0' in 'C:\Users\myuser\NugetTest'.
Retrieving package 'Telerik.Windows.Controls.for.Wpf 2024.3.924' from 'https://nuget.my.domain/nuget/Telerik/v3/index.json'.
Retrieving package 'Telerik.Windows.Controls.Input.for.Wpf 2024.3.924' from 'https://nuget.my.domain/nuget/Telerik/v3/index.json'.
Retrieving package 'Telerik.Windows.Controls.Navigation.for.Wpf 2024.3.924' from 'https://nuget.my.domain/nuget/Telerik/v3/index.json'.
Retrieving package 'Telerik.Windows.Controls.RibbonView.for.Wpf 2024.3.924' from 'https://nuget.my.domain/nuget/Telerik/v3/index.json'.
Retrieving package 'Telerik.Windows.Data.for.Wpf 2024.3.924' from 'https://nuget.my.domain/nuget/Telerik/v3/index.json'.
Package 'System.Data.OleDb.7.0.0' already exists in folder 'C:\Users\myuser\NugetTest'
Successfully installed 'System.Data.OleDb 7.0.0' to C:\Users\myuser\NugetTest
  NotFound https://nuget.my.domain/nuget/Telerik/v3/flatcontainer/Telerik.Windows.Controls.for.Wpf/2024.3.924/Telerik.Windows.Controls.for.Wpf.2024.3.924.nupkg 1018ms
WARNING: Install failed. Rolling back...
Executing nuget actions took 1.22 sec
Package 'Telerik.Windows.Controls.for.Wpf.2024.3.924 : System.Data.OleDb [7.0.0, )' is not found on source 'https://nuget.my.domain/nuget/Telerik/v3/index.json'.

The api-key works when configured directly on visual studio and the user is able to download the packages directly from the internet.
We are on the latest available version of Proget (2024.15) on Windows.

I havent found any logs that could help troubleshooting. If needed I can temporarly provide you the API Key to test it on your side, privately.
Thanks in advance for your help.

Hi, I can confirm that now the CPU usage is stabilized and we don't have errors in the Proget logs. To be fair we also addeed some storage and retention rules that have cleaned up a lot of our feeds (we purged about 50-60% of the cached packages) and probably this helped too.

Hi @atripp ,
we applied the alter of the procedure, at the moment everything looks fine and the CPU performance on the SQL server seems back to a normal usage. I'll keep you posted to confirm if everything goes well for a day or two.

Thanks

We thought that the error was caused by another DB using a lot of CPU on the same SQL Server but in fact the problem is still there and was not caused by that.
Is there anything that we can do to help you trubleshoot this issue that we are having?

Hi, yesterday we updated to the latest available Proget version and after that we started to see this error in the logs:

An error occurred processing a GET request to https://nuget.ges.ferlan.it/nuget/default/FindPackagesById()?id='Humanizer.Core.uz-Latn-UZ'&semVerLevel=2.0.0: Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

Microsoft.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
---> System.ComponentModel.Win32Exception (258): The wait operation timed out.
at Microsoft.Data.SqlClient.SqlCommand.<>c.<ExecuteDbDataReaderAsync>b__209_0(Task`1 result)
at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
at Inedo.Data.DatabaseContext.DbResult.CreateAsync(DbCommand command, DatabaseContext context, DateTimeOffset startTime, Stopwatch stopwatch)
at Inedo.Data.DatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.Data.SqlServerDatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.Data.DatabaseContext.ExecuteTableAsync[TRow](String storedProcName, GenericDbParameter[] parameters)
at Inedo.ProGet.Feeds.NuGet.V2.LocalPackageSource.FindPackagesByIdAsync(NuGetQueryOptions options, String id)
at Inedo.ProGet.Feeds.NuGet.NuGetFeed.FindPackagesByIdAsync(NuGetQueryOptions options, String id)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.ODataQueryHandler.FindPackagesById(String id)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.ODataHandler.ProcessVirtualRequestAsync(ODataResponseContext context, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.ODataHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetFeedHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(AhHttpContext context)
ClientConnectionId:f32aa96d-5f9a-4b04-8696-6af4f1a92b03
Error Number:-2,State:0,Class:11

This is happening with multiple packages, not just the one in the example. Multiple times a day:

This request is putting a strain in the SQL server where we see high CPU usage on the Proget DB. This is the query causing a very high CPU usage:

SELECT *
	  FROM [NuGetFeedPackageVersions_Extended] 
	 WHERE [Feed_Id] = @Feed_Id
	   AND [Package_Name_Lower] = LOWER(@Package_Id)
	   AND (@Version_Text IS NULL OR [Package_Version] = @Version_Text)

Maybe the last line is the issue?
Any help is much appreciated.
Thanks

@atripp We applied the script, can confirm that we are not getting the error anymore. Thanks!

Hi, we are having the exact same error when opening a Maven feed, after updating to the latest version. Should we execute the same SQL script and change the view?

@shfunke_1795 said in Support for Alpine Packages:

Hey,
for building Docker images we'd like to use internal mirrors
for Debian and Alpine packages, right now Alpine is not supported.
The support of Alpine packages would be a benefit not only
for internal builds on machines without internet access but
also in regards of security as then these packages would be
included in the security scans for projects under Reporting & SCA.

we are in the same scenario and it would be great to be able to rely on proget for this work.
we are long-time customers of proget and it would make our lives a lot easier.
Best regards.