inedo-engineer

@pmsensi sure thing!

2025.16-rc.1 should be available now.

Here's how to download it:
https://docs.inedo.com/docs/installation/windows/inedo-hub/howto-install-prerelease-product-versions

Hi @pmsensi

Are you able to easily test a pre-release container? I wasn't sure if you're on Linux/Docker, but I just made a code change (PG-3164) that should show up soon as inedo/proget:25.0.16-ci.1

Let me know if you're able to try that -- if you're on Windows, I can push a package for the Ineod Hub to download as well.

Thanks,

Alana

Hi @parthu-reddy ,

This can particular occur when there are some issues with the database, such as outdated statistics or highly-fragmented indexes. This script should help fix this:
https://proget.inedo.com/endpoints/Public/content/DefragmentIndexesWithRowCount.sql

It coudl be something else, but the query that page uses seems to be mostly effected by those.

Thanks,
Alana

Hi @parthu-reddy ,

This error means that PowerShellGallery.com is taking too long to respond to that query. You can try increasing the connector timeout; it's 10 seconds by default. Maybe try 20 or 30 seconds? Just a guess.

Unfortunately the PowerShellGallery seems to be in a state of abandonment these days and it performs really poorly. It's pretty buggy too.

I would consider using a multi-feed, package-approval process to pull packages so you don't have to rely on the gallery's API.

Cheers,
Alana

Hi @jw,

Unfortunately there's no easy way to guess which name is "correct", so sometimes the "wrong" name gets de-duplicated. This also should have no real side-effect, except perhaps seeing the "wrong" casing in some places.

However, as you noticed, the name is overwritten when a package is added to a feed. So, if jquery is the package name stored in the database, that record will be updated to jQuery upon upload of a package.

This doesn't seem to impact many packages at all.

Thanks,
Alana

Hi @pmsensi,

Nice find. So we can't make it a configurable value, but we can try finding something that works with pipy.org, which is the main requirement.

According to the example posted in their docs, this might be what a Simple API might look like:

# Construct our list of acceptable content types, we want to prefer
# that we get a v1 response serialized using JSON, however we also
# can support a v1 response serialized using HTML. For compatibility
# we also request text/html, but we prefer it least of all since we
# don't know if it's actually a Simple API response, or just some
# random HTML page that we've gotten due to a misconfiguration.
CONTENT_TYPES = [
    "application/vnd.pypi.simple.v1+json",
    "application/vnd.pypi.simple.v1+html;q=0.2",
    "text/html;q=0.01",  # For legacy compatibility
]
ACCEPT = ", ".join(CONTENT_TYPES)

So I guess, could you try that header?

application/vnd.pypi.simple.v1+json, application/vnd.pypi.simple.v1+html;q=0.2, text/html;q=0.01

Thanks,
Alana

Hi @dubrsl_1715

I was sure that you must be interested in creating a product that would solve real tasks.

Not really :)

As a products company, we solve problems that a sufficient number of users would be willing to pay for and that aligns with our overall strategic vision.

We also do User-Driven Development, which means we prioritize helping our existing users/customers solve problems instead of adapting the product for nonusers/evaluators like you guys.

We don't consider packagist a competitor nor are we currently marketing users to switich; our solution is similar but not an analog. It requires a change to your workflow.

The PHP/Composer market is already hyper-niche and I'm not convinced there's enough demand to develop a "versionless" package format (i.e. where a version number cannot be discovered in the manifest file or the package file name) format just for this particular use case (i.e. alternate workflow / simpler migration from packagist).

None of the other feed types have this requirement, and it'd be nontrivial to modify our model to support this unique requirement. It would have downstream impacts to features like replication, disk-importing, reindexing, etc.

Thanks,

Alex

Hi @dubrsl_1715 ,

I don't think ProGet is the right solution for you guys. Supply Chain Security and OSS Governance are clearly not concerns, and you're simply not going to get any real value out of a product designed to help organizations solve those problems at the cost of convenience.

I think you will be much better served with the free/OSS repositories for your various repositories; we call that Level 2 in Package Maturity, and I can't imagine any of the "pain points" articulated in that article will resonate.

There's nothing wrong with that. As I've always said, sometimes a Source Control Shingle is the right tool for the job.

Best,
Alex

Hi @jw ,

Thanks for confirming that; we were able to identify the bug -- this time it ws SQL-server specific.

This is fixed via PG-3163, which we're shipping in this week's maintenance release. You'll still need to de-deduplication after however.

Tanks,
Alana

Hi @pmsensi ,

You'd need to run through a proxy like Fiddler or ProxyMan, which can capture the outbound / inbound traffic. Or if you provide us with a URL/API key we might be able to play around and attach a debugger. You could always create a free trial or something and set it up that way.

First thing that comes to mind is that your endpoint is incorrect and you may need to "play around" with the URL. Typically it's like this:

• endpoint is https://server.corp/path/my-pypi
• index file is https://server.corp/path/my-pypi/simple
• ProGet automatically appends /simple unless you specify otherwise on Advanced

The "Simple " endpoint is just a list of HTML like <a href="...">. That's what ProGet/connectors/pypi follow.

Thanks,

Steve