Discard markers on editable requirements

[charliermarsh]

Summary

If a user includes markers after an editable, we now ignore them (rather than including them in the parsed URL). This matches pip's behavior. In the future, we could further improve by respecting them, but that would be a deviation from pip.

For example, given:

-e ./scripts/packages/black_editable ; python_version >= "3.9" and python_ver

We now split at the first whitespace (just before the ;), parse everything before, and throw out everything after.

This logic also extends to extras. So given:

-e ./scripts/packages/black_editable[dev, colorama]

We'll now parse this as the URL ./scripts/packages/black_editable[dev,, and throw out colorama]. Instead, you need to do:

-e ./scripts/packages/black_editable[dev,colorama]

(I.e., remove the space.)

This also matches pip's behavior. I could "fix" this but I'm unsure if I should -- it means requirements files will be parseable by uv that won't work with pip. Open to input. My gut reaction is that we should properly support -e ./scripts/packages/black_editable[dev, colorama] even if pip would reject it, but requirements.txt is implementation-defined so it'd be a "deviation".

Closes #3604.

[konstin]

This file contained some regression tests for whitespace behavior in the parser

[charliermarsh]

I’m pretty sure those exist in a separate file. This was just a duplicate of another test file, no?

[konstin]

To me, pypa/pip#8581 (comment) makes it look like this is a bug in pip, could we check back with the pip devs on this?

[charliermarsh]

I don’t think it’s a bug. I think it’s an intentional limitation right now because it’s not covered by any standard. For that reason I’m also somewhat hesitant to support it… It also means that files that work with uv won’t work with pip.

[charliermarsh]

Ok, I decided to change the behavior to continue to allow spaces between extras in editables (i.e., we continue to support -e /editable[d, dev]).