it's possible that #897 caused this bug

I'm struggling to construct a url:Url which seralizes to file:///${PROJECT_ROOT}/../a.

• Url:parse("file:///${PROJECT_ROOT}/../a") and url.set_path("${PROJECT_ROOT}/../a") will shorten the .., resulting in file:///a.
• Url::from_file_path("/${PROJECT_ROOT}/../a") panics on Windows.

The only workaround I've found is to force using absolute path on Windows, as shown in the original commit of #897.

I see. Maybe we should avoid using the Url type if it can't represent this on Windows, maybe we can do so only for relative paths? I could look into that kind of change.

Uv supports relative paths directly, astral-sh/uv#1027 but that's a divergence from pip and requirements syntax I think

Reverting just #897 doesn't help, there's also a change related to uv that contributes to this.

The ${} syntax ends up url escaped like file:///$%7BPROJECT_ROOT%7D/../a - multiple places in rye use format_requirement to undo this escaping, and if that's done when rye uses uv to resolve this URL too, that will work like it did previously.

Using relative paths instead of these strange URLs is viable at least if using only uv in the future, otherwise these URLs seem like the most "portable" way to handle relative paths right now. One reason is that pip install from requirements files accepts lines like "foo @ file:///some/url" but not "foo @ /some/path"

It would be good to update the pep508_rs crate and use VerbatimUrl in the new version (assuming it can do this better?), but it's not a trivial upgrade.

Hey ! Just following up on this, I'm trying to add a module with a relative path, but I end up either with a broken path, or with an absolute path (which obviously can't be put inside of a git repository for anyone to work on).

Here the details of what I want to do.

Command :

rye add tester-common-lib --path "../mysuperlib"           

Output :

error: Failed to run uv compile error: Distribution not found at: file:///mysuperlib
. uv exited with status: exit status: 2

The following command will work, but, as the parameter suggest, it will create an absolute path in the pyproject.toml file, which I can't push into a repository for others to work on..

Command :

rye add tester-common-lib --path "../mysuperlib" --absolute          

Pyproject content :

"mysuperlib @ file:///home/redat00/Documents/perso/it/app/app-api/../mysuperlib",

Would love for the solution that @bluss wrote in #928 to at least be reviewed if possible. In my case this feature is important for me, and I would love to use Rye on my project ! 🙏

Thanks!

@redat00 The workaround I think you can use right now is to update the pyproject.toml directly, the problem here is with rye add and not other parts of needed steps (like rye sync) - at least I don't know of any problems there. Consider if you want to use a (non virtual) pdm build backend for the root instead, since then it should be more well defined how standard Python tools will treat your pyproject.toml-defined project.

Indeed I was able to make it work with the latest version of Rye by manually adding the following :

    "mysuperlib @ file:///${PROJECT_ROOT}/../mysuper",

Thanks !