implement omit_trailing_slash feature for PyUrl [7186]

[tworedz]

Change Summary

Based on comment pydantic/pydantic#7186 (comment) implemented omit_trailing_slash feature for PyUrl crate.

Related issue number

pydantic/pydantic#7186

Checklist

• Unit tests for the changes exist
• Documentation reflects the changes where applicable
• Pydantic tests pass with this pydantic-core (except for expected changes)
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @dmontagu

[tworedz]

please review

[codecov]

Codecov Report

Merging #1218 (ca4b802) into main (ab503cb) will increase coverage by 0.08%.
Report is 28 commits behind head on main.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1218      +/-   ##
==========================================
+ Coverage   90.21%   90.29%   +0.08%     
==========================================
  Files         106      106              
  Lines       16339    16423      +84     
  Branches       36       39       +3     
==========================================
+ Hits        14740    14829      +89     
+ Misses       1592     1575      -17     
- Partials        7       19      +12     

Files	Coverage Δ
python/pydantic_core/core_schema.py	94.70% <100.00%> (-0.07%)	⬇️
src/serializers/infer.rs	95.12% <100.00%> (ø)
src/url.rs	98.25% <100.00%> (-0.07%)	⬇️
src/validators/url.rs	97.16% <100.00%> (+0.05%)	⬆️

... and 5 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c6301fe...ca4b802. Read the comment docs.

[codspeed-hq]

CodSpeed Performance Report

Merging #1218 will not alter performance

_{Comparing tworedz:omit-trailing-slash (ca4b802) with main (c6301fe)}

Summary

✅ 148 untouched benchmarks

[davidhewitt]

Prior art: #1173. Is there a reason why this route should be seen as preferred to the broader suite of normalization bugs which that PR discussed (and ultimately decided we need fixes in rust-url to resolve)?

[tworedz]

Prior art: #1173. Is there a reason why this route should be seen as preferred to the broader suite of normalization bugs which that PR discussed (and ultimately decided we need fixes in rust-url to resolve)?

In my humble opinion, there seem to be two related yet slightly different issues that we are trying to tackle. The #1173 PR is aimed at fixing the broken Url.build feature, as discussed earlier, and this should be addressed through modifications to rust-url.

Modifying the behavior of rust-url to accommodate URL processing, a functionality relied upon by all users of this crate, appears to be quite challenging. However, from the perspective of pydantic, this was the previous behavior that many projects accepted and utilized, and they aim to continue using it in v2.

What are your thoughts on this?

[davidhewitt]

Let me reflect on this. My instinct is that this is still a rust-url issue, but I may need to prompt discussion upstream.

[tworedz]

Thanks!

[davidhewitt]

(Just to set expectations, I've set myself a reminder to explore this next week, when I expect to be also picking up #1085 again. Please ping me if this PR falls off my radar.)

[tworedz]

Great! I'll glad to any response)

[tworedz]

@davidhewitt Hey, could you please provide updates?)

[davidhewitt]

I have been thinking about this a bit. I would like to avoid the config flag if we can. It seems to me that it's a problem that the URL does not round-trip, and this seems to be a problem of rust-url, which apparently follows the WHATWG URL spec, so I think that first I want to understand if the spec expects this behaviour, or it's a rust-url bug.

[sydney-runkle]

@davidhewitt, what do next steps look like here? Do we still plan on attempting to implement this?