Remote packages that isnt cached does not format correctly

[gisleso]

Hello ProGet users and devs!

We have a server running on Linux server using podman and nginx reverse proxy. We have two feeds where one has a connector to the other. We want one feed with approved packages, and a team specific feed where they promote a subset for their own development (strict license requirements etc).
We have this configured using the internal hostname for the ProGet container (connector traffic does not leave the container).

But I'm starting this topic to ask if its expected behavior that formatting of uncached remote packages is a litte off? See screenshots.

And if anyone have experience with promoting packages including their dependencies I am open to suggestions. (Right now I'm thinking a script that first pull the packages, and the loop to pull/promote the depedencies)

Examples where "approved-pypi" is all approved packages, and "promoted-pypi" is our team specific feed with a subset of packages.
We have taken inspiration from the "Effective-Package-Management-in-Python" e-book.

Looking forward to your replies,
Gisle S.

[dean-houston]

Hi @gisleso,

But I'm starting this topic to ask if its expected behavior that formatting of uncached remote packages is a litte off? See screenshots.

Good catch. In this case, the ProGet implementation of the warehouse API (which connectors use) was using the "description" field instead of the "summary" field. Easy fix, it'll be handled via PG-3151 in the next maintenance release

And if anyone have experience with promoting packages including their dependencies I am open to suggestions. (Right now I'm thinking a script that first pull the packages, and the loop to pull/promote the depedencies)

This is frequently requested, but it's simply impossible to do. The only way to solve this is to restore from your unapproved feed, then promote the dependencies into your approved feed.

The reason is that this would require ProGet (or your script) to perform a "dependency resolution" which is impossible to do without environmental context (i.e. other packages installed, operating system, and client configuration).

This is because dependencies are not only specified as ranges (e.g. hypothesis requires sortedcontainers<3.0.0,>=2.1.0) but they often include usage constraints (e.g. hypothesis specifies redis>=3.0.0; when extra=="redis" is specified) and environmental constraints (e.g. hypothesis specifies tzdata>=2025.2 but only when (sys_platform == "win32" or sys_platform == "emscripten") and extra == "zoneinfo").

Only a package manager tool (e.g. pip) can perform dependency resolution, and even then it's not deterministic. This is why lock files are so important too.

-- Dean

[gisleso]

@dean-houston, thanks for fixing that bug and detailed response to dependencies.