uv venv fails on Windows when using ramdisk

[Artalus]

I have a ramdisk created via ImDisk that I use as a temporary directory. Apparently uv does not like such setup:

# uv works alright on a regular disk
PS E:\1> uv venv
Using Python 3.11.3 interpreter at: C:\python\311\python3.exe
Creating virtualenv at: .venv
Activate with: .venv\Scripts\activate

# uv fails on ramdisk
PS E:\1> cd r:/1
PS R:\1> uv venv
thread 'main' panicked at crates\uv-fs\src\path.rs:17:10:
The current directory must be canonicalized: Os { code: 1, kind: Uncategorized, message: "Incorrect function." }
stack backtrace:
   0:     0x7ff780d71fdd - <unknown>
   1:     0x7ff780d99cb9 - <unknown>
   2:     0x7ff780d6bbe1 - <unknown>
   3:     0x7ff780d71db6 - <unknown>
   4:     0x7ff780d747b8 - <unknown>
   5:     0x7ff780d74466 - <unknown>
   6:     0x7ff780d74ce8 - <unknown>
   7:     0x7ff780d74ba7 - <unknown>
   8:     0x7ff780d7294f - <unknown>
   9:     0x7ff780d74858 - <unknown>
  10:     0x7ff780ed5e84 - <unknown>
  11:     0x7ff780ed6320 - <unknown>
  12:     0x7ff780c6605b - <unknown>
  13:     0x7ff7800a975e - <unknown>
  14:     0x7ff780ed50a4 - <unknown>
  15:     0x7ff7800abbde - <unknown>
  16:     0x7ff77fa82162 - <unknown>
  17:     0x7ff77fa1d797 - <unknown>
  18:     0x7ff77fb01ddd - <unknown>
  19:     0x7ff77fe282ed - <unknown>
  20:     0x7ff77fc95bb4 - <unknown>
  21:     0x7ff77fe28f8a - <unknown>
  22:     0x7ff77fdd28ff - <unknown>
  23:     0x7ff78010ea1a - <unknown>
  24:     0x7ff77fdd4056 - <unknown>
  25:     0x7ff780d62c9e - <unknown>
  26:     0x7ff78010ea5c - <unknown>
  27:     0x7ff780e466bc - <unknown>
  28:     0x7ffb3de47374 - BaseThreadInitThunk
  29:     0x7ffb3e71cc91 - RtlUserThreadStart
PS R:\1> uv version
uv 0.2.31 (48162de97 2024-07-29)

# python 3.11 works on ramdisk
PS R:\1> python -m venv venv
PS R:\1> ls venv/Scripts/activate
-a----        2024-07-31  05:35 PM           2049 activate

I am pretty sure that Python's own python -m venv used to have some issues with ramdisks as well - the "must be canonicalized" error message does ring some bells.

[zanieb]

This comes from

uv/crates/uv-fs/src/path.rs

Lines 13 to 18 in 24859bd

	pub static CANONICAL_CWD: LazyLock<PathBuf> = LazyLock::new(|| {
	std::env::current_dir()
	.expect("The current directory must exist")
	.canonicalize()
	.expect("The current directory must be canonicalized")
	});

I'm not sure why it must be canonicalized. Seems like we could allow that to fail... hm.

[Artalus]

Reading through the release notes and 0.5.0 got my attention with

Previously, uv canonicalized the path to the Python executable when setting the Python path in created virtual environments. This behavior had several undesirable effects: it would bypass stabilized version directories (as constructed by Homebrew) and it was not consistent with the Python standard library's behavior. Now, uv uses the sys._base_executable path.

Whether it was #8481 or not, my issue now appears to be fixed with uv 0.5.26 installed from Scoop; both uv venv & uv pip install behave as usual.
@zanieb feel free to close this issue and do with it what your workflows require.

Thank you for your work, I adore this little tool 💚

[zanieb]

Oh great! Thank you!

<3