Update pep508_rs and pep440_rs

[bluss]

Update pep508_rs and pep440_rs crates

Main reason is to use VerbatimUrl from pep508_rs and try to fix issues around file:///${PROJECT_ROOT}/etc dependencies.

Note that monotrail-utils is still using the older pep508_rs.

Fixes #912

[bluss]

This is in an attempt to solve #912. In this case by using the real absolute path as the Url part of VerbatimUrl and the ${PROJECT_ROOT}/../relative path as the "given" part of the URL, let's see how that works out.

Remains to be done

• test the monotrail dependent import.
• check if using VersionPattern correctly
• Add additional tests for Can't add relative path dependencies in virtual project #912

[bluss]

Now it's working, but it certainly does not feel solid around VerbatimUrl and ${}'s.

[bluss]

rebased x3

[bluss]

Feedback on this is welcome. Updating these crates is ok? Fixing relative paths is ok or a bad idea? We could go other ways, like adopting another convention for relative paths than the ${PROJECT_ROOT} stuff here, for example going all in on uv-style relative paths?

[charliermarsh]

Can you explain why the original failure is happening? I.e., why is PROJECT_ROOT problematic in a virtual project?

[bluss]

The bug is just general to rye add with relative paths.

The default rye init project is not virtual and build system is hatchling. In this configuration, currently, Rye does not support relative paths with git add. It just makes them absolute. So, no bug with the default project because there are no relative paths.

This bug shows up in for example rye init --virtual and rye init --build-system pdm projects where rye add thinks it supports relative path dependencies (the conditional is build_system != hatchling), and fails to construct the URL for it.

So we could say that ${PROJECT_ROOT} is always problematic for rye add currently - it seems to work in rye sync though.

This PR is my attempt to fix this in a "minimal" way. It's not great that the PR mixes two things - updating deps and fixing bugs in add, but when I wrote this I didn't want to leave stuff in a half broken state. (I even had the energy to write tests. They are not there because I'm a nice guy, it's because I want this functionality to keep working 😉 )

[bluss]

There's a lot more we'd like to do with relative paths, but I need some buy in from @mitsuhiko I feel. It would be great to adopt some ideas from uv where you have done the hard work of finding out what's interoperable with pip and what is not - see PR astral-sh/uv#3682

[bluss]

rebased and dropped the changelog update because the newest changelog seemed to be autogenerated