Handle malformed version metadata error and skip the package

[sepehr-rs]

Fixes #13443 by wrapping the version property in _dists.py with a try/except block and handling the fallback in _envs.py.
I saw @pfmoore’s suggestion that raising an error might be the better approach, but after observing how pip handles invalid name metadata entries, I chose not to modify the rest of _envs.py that handles error reporting to keep things simple for now. I'm more than happy to revisit that part if needed. Feedback is very welcome!

[sepehr-rs]

I fixed the pre-commit errors, but I think the pre-commit test didn't run correctly cause it's still failing on a line that I changed.
I would really appreciate any help on how to fix the other failing tests :).

[notatallshaw]

That is odd, I'm not sure why pre-commit is doing that.

[notatallshaw]

Though the failing tests do need to be fixed, it is important that users can continue to uninstall packages even if the version is invalid.

[sepehr-rs]

Though the failing tests do need to be fixed, it is important that users can continue to uninstall packages even if the version is invalid.

I followed the same approach used for the Name metadata value, so I'm unsure how to proceed from here.
Also, how would you recommend I proceed with the failing tests? Should I update the tests themselves, or is there an issue with my implementation?

[pfmoore]

@notatallshaw is that a behaviour change, though? The original issue #13443 suggests that there is already an error (just an unhandled exception, not a “proper” error). If we’ve turned working code (uninstalling a project with an invalid version) into a failure, that suggests the fix has modified something it shouldn’t.

I'm not against allowing the uninstall of packages with an invalid version, but the “blast radius” of this PR seems to have become larger than the original issue…

[sepehr-rs]

@notatallshaw is that a behaviour change, though? The original issue #13443 suggests that there is already an error (just an unhandled exception, not a “proper” error). If we’ve turned working code (uninstalling a project with an invalid version) into a failure, that suggests the fix has modified something it shouldn’t.

I'm not against allowing the uninstall of packages with an invalid version, but the “blast radius” of this PR seems to have become larger than the original issue…

Thank you for your comment, @pfmoore, I appreciate the feedback. From what I can tell, this approach seems consistent with how the Name metadata value is handled, so I'm still trying to understand why it might not be appropriate here. I hope I’m not overlooking something obvious — I'm still learning the nuances of contributing to FOSS and genuinely eager to improve.

[pfmoore]

I don't think there's a justification for the changes in _envs.py.

[notatallshaw]

@notatallshaw is that a behaviour change, though?

The PR is already updated at this point (thanks @sepehr-rs ), but going back to this, yes, users have been able to fix their issue by uninstalling the package using pip, we've had several GitHub issues raised where this has been the confirmed solution.

[pfmoore]

Thanks, @notatallshaw - once I'd realised that the problem was the extra, unnecessary, check, it became obvious that was what was impacting the uninstall command.

This now looks OK to me. I won't merge yet, as I think @ichard26 wants to keep main frozen for a while in case we need a bugfix release for 25.3.