-
Notifications
You must be signed in to change notification settings - Fork 387
Question: syntax for abs paths passed as file://
URLs in Windows?
#3730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Seeing comments like this one: mamba/libmamba/include/mamba/util/url.hpp Lines 186 to 192 in 31b2347
makes me think it should be accepted? |
Per this blogpost from the IE team back in 2006, the proper syntax is as follows: ![]() |
Reading the mamba/libmamba/src/util/url_manip.cpp Lines 88 to 133 in 0abd7d5
And testing some more, it seems >>> from libmambapy.specs import CondaURL
>>> CondaURL.parse("file:////D:/a_/temp/popen-gw0/test_croot_with_spaces0/space%20path")
file:////D:/a_/temp/popen-gw0/test_croot_with_spaces0/space%20path |
It works with 4+ leading |
Is this a question or more like a bug? 🤔 |
When using 2 or 3 slashes, the error is the same (
It seems that only |
I believe that indeed
It's not clear to me why a 4th |
Hum, what do you use exactly when you test with curl? Is it a command line? |
Yes that's when using the My understanding so far is that in no cases does |
Yes I mean the issue seems to be related to |
So what's the status here? Are we supposed to pass four slashes, three, two...? Or should this be handled internally in libmamba so library users are not exposed to implementation details in libcurl? |
Sorry for the late answer, Mamba should supports any valid URI, independently from curl. Its implementation detail should not leak to the end user. EDIT: labelling this as a bug. |
Actually, the issue is only reproducible when we try to parse |
We observed it at https://github.com/conda/conda-build/blob/5cd0aa447fc78abad7f201ebd72a30229c7cf1ef/tests/test_api_build.py#L1439-L1450, Windows only. |
Hmm, could that be a difference in |
The CI is not done yet, but I can already see that the test also fails with libcurl from conda-forge:
|
Locally, on Linux, with the attached >>> from libmambapy.specs import CondaURL
>>> url = CondaURL.parse("file:///D:/a/_temp/popen-gw0/test_croot_with_spaces0/space%20path")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
libmambapy.bindings.specs.ParseError: Failed to parse URL "file:///D:/a/_temp/popen-gw0/test_croot_with_spaces0/space%20path": Bad file:// URL
>>> url = CondaURL.parse("file:///D:/a/_temp/popen-gw0/some_other_parts")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
libmambapy.bindings.specs.ParseError: Failed to parse URL "file:///D:/a/_temp/popen-gw0/some_other_parts": Bad file:// URL
|
On Windows, the number of slashes does not seem to cause an issue, but unencoded spaces do: >>> from libmambapy.specs import CondaURL
# Any number of slashes are parsable, but 4 introduces an extra leading slash
>>> CondaURL.parse("file://D:/a/_temp/popen-gw0/some_other_parts").path()
'/D:/a/_temp/popen-gw0/some_other_parts'
>>> CondaURL.parse("file:///D:/a/_temp/popen-gw0/some_other_parts").path()
'/D:/a/_temp/popen-gw0/some_other_parts'
>>> CondaURL.parse("file:////D:/a/_temp/popen-gw0/some_other_parts").path()
'//D:/a/_temp/popen-gw0/some_other_parts'
# Backslashes are ok
>>> CondaURL.parse("file://D:\\a\\_temp\\popen-gw0\\some_other_parts").path()
'/D:\\a\\_temp\\popen-gw0\\some_other_parts'
# Spaces break it, no matter the number of slashes
>>> CondaURL.parse("file://D:/a/_temp/popen-gw0/some_other_parts spaces").path()
Traceback (most recent call last):
File "<python-input-22>", line 1, in <module>
CondaURL.parse("file://D:/a/_temp/popen-gw0/some_other_parts spaces").path()
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
libmambapy.bindings.specs.ParseError: Failed to parse URL "file://D:/a/_temp/popen-gw0/some_other_parts spaces": Malformed input to a URL function
>>> CondaURL.parse("file:///D:/a/_temp/popen-gw0/some_other_parts spaces").path()
Traceback (most recent call last):
File "<python-input-23>", line 1, in <module>
CondaURL.parse("file:///D:/a/_temp/popen-gw0/some_other_parts spaces").path()
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
libmambapy.bindings.specs.ParseError: Failed to parse URL "file:///D:/a/_temp/popen-gw0/some_other_parts spaces": Malformed input to a URL function
>>> CondaURL.parse("file:////D:/a/_temp/popen-gw0/some_other_parts spaces").path()
Traceback (most recent call last):
File "<python-input-24>", line 1, in <module>
CondaURL.parse("file:////D:/a/_temp/popen-gw0/some_other_parts spaces").path()
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
libmambapy.bindings.specs.ParseError: Failed to parse URL "file:////D:/a/_temp/popen-gw0/some_other_parts spaces": Malformed input to a URL function
# Encoded spaces are ok
>>> CondaURL.parse("file://D:/a/_temp/popen-gw0/some_other_parts%20spaces").path()
'/D:/a/_temp/popen-gw0/some_other_parts spaces'
>>> CondaURL.parse("file:///D:/a/_temp/popen-gw0/some_other_parts%20spaces").path()
'/D:/a/_temp/popen-gw0/some_other_parts spaces'
>>> CondaURL.parse("file:////D:/a/_temp/popen-gw0/some_other_parts%20spaces").path()
'//D:/a/_temp/popen-gw0/some_other_parts spaces' This platform specific behavior is confusing 🤔 |
Yes that was what confused me in the beginning when trying a fix on linux. So on linux/macos, the error is reproducible indeed (with Any other concerns? |
I opened conda/conda-libmamba-solver#640 to handle the percent encode for now. If these are handled internally in libmamba, even better. Agreed that the slash behavior should be consistent across platforms. |
Thinking more about this, encoding spaces may open the door to other inconsistencies - when the URI contains specific characters that shouldn't be encoded (besides the If we choose to encode spaces only with file URLs, wouldn't that make it inconsistent as well (with regards to other URLs)? |
On one hand, we are already using In previous versions, we were escaping channel URLs as a norm: https://github.com/conda/conda-libmamba-solver/blob/f7b559f422e9fb416a9c33b5d134fecd15f4262e/conda_libmamba_solver/index.py#L87-L98, but we are not doing that anymore because apparently we didn't need to? It does look like mamba v2 has some logic for percent encoding already, so I'm not sure why this case is not covered. |
It seems that the percent encoding is used in specific cases, either for setting a package, or setting parts of the url (user, password, etc), or when converting from path to file urls. |
I think the overall rule is to always encode the path component of a URL (excluding |
CondaURL::parse is actually relying on I found this in the docs:
but definitely lacking some tests and maybe also some comments in the codebase... |
What's the actual way? Given this absolute path in Windows
D:\a_\temp\popen-gw0\test_croot_with_spaces0\space path
:Only the last one (without the
:
in the drive letter) is accepted, but not sure if that's understood as a Windows path internally? Should I always remove the:
in the drive?The text was updated successfully, but these errors were encountered: