I am running into a blocking issue regarding a Composer feed that has a connector configured for Packagist.

Currently, packagist.org supports non-standard version names, such as branch names or custom plain-text strings. However, ProGet rejects these packages, seemingly because it strictly enforces the version schema outlined in the official Composer specification (https://getcomposer.org/doc/04-schema.md#version).

While I understand the desire to stick to the strict schema, the Composer specification explicitly states that the version field is not always mandatory and can be inferred in certain scenarios. As the documentation states:

"Optional if the package repository can infer the version from somewhere, such as the VCS tag name in the VCS repository. In that case it is also recommended to omit it."

Since packagist.org leverages this rule and infers versions from VCS (allowing for non-standard versions like branch names), ProGet's strict validation ends up breaking the sync and rejecting these packages.

The Request:
Could ProGet be updated to mirror the same version validation rules and leniency used by packagist.org, specifically taking into account that the version can be optional or non-standard when inferred from VCS?

Impact:
Right now, this strict validation completely blocks the use of ProGet for large projects that rely on upstream dependencies with these non-standard version names. We are unable to successfully proxy/cache these packages.

Thank you for looking into this! Please let me know if you need any logs or further examples.

Without knowing which specific package you're referring to, it's hard to give a more specific example.

Historically, Packagist was effectively a database of "GitHub Repository pointers" and Composer was effectively just a wrapper around the Git client. They can both still operate in that mode, and needs to for older, non-standard packages. I suspect that's the type of package you're referring to here.

ProGet's Composer feeds work with "packages" (i.e. not the GitHub pointers), which account for nearly all of the modern packages on Packagist.org. For the small number of packages that don't follow the standard (mostly older, legacy packages), you'll need to download them, properly package them, and then upload them to follow the standard.

Unfortunately there's no technically feasible/sensible way to solve this problem - since it would require ProGet to serve as a GitHub pointer database, which just doesn't make sense.

Cheers,
Steve