Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
I’m currently trying to write a Python program. The Python program that I’m working on seems to work fine on Linux, but it sometimes breaks when I run it on Windows. Specifically, it breaks breaks because it sometimes tries to create new directories using DOS paths (see The Definitive Guide on Win32 to NT Path Conversion) that are longer than 260 characters.
As far as I know, there are two possible workarounds for Windows’s 260 character MAX_PATH limitation. The first workaround is to do the following:
Make sure that the executable file has an application manifest that sets longPathAware to true.
This is kind of a problem for Python programs. When you create a Python program, you don’t create an executable file. Instead, the executable is provided by whatever implementation of Python the user has chosen to use. As far as I know, there’s no guarantee that all Python implementations will have an application manifest that sets longPathAware to true. So I don’t think that it would be a good idea to depend on something like that.
Make sure that everyone who uses the application on Windows has "LongPathsEnabled" set to dword:00000001 in their registry.
I’m not sure why this specific registry key-value pair is required, but the fact that it exists implies that there are some applications that say that they are longPathAware but break if you actually give them long DOS paths (otherwise, why would there be an option to turn off long DOS paths for longPathAware applications?). I wouldn’t want to force users to turn on a setting that might break other applications just so that they can run my program.
I don’t want to use the first workaround because of the above limitations that I described. This leaves me with the second workaround. The second workaround is to make sure that all DOS paths that are longer than 260 characters are Root Local Device paths (i.e., DOS paths that begin with \\?\, see The Definitive Guide on Win32 to NT Path Conversion). In order to do this, I need a function that will convert an arbitrary DOS path into a Root Local Device path.
I haven’t been able to find a function in the Python ecosystem that converts arbitrary DOS paths into Root Local Device paths. Rust’s std::fs::canonicalize() function almost does what I want, but it doesn’t work for DOS paths that don’t exist yet. Luckily, there’s a soft-canonicalize package on crates.io which can be used to convert nonexistent DOS paths into Root Local Device paths.
So my current strategy for dealing with this problem is to use Maturin to create a Python module that’s written in Rust. The Python module will use the Rust soft-canonicalize package to convert arbitrary DOS paths into Root Local Device paths. If I understand correctly, this means that I will end up distributing a Python wheel that contains compiled Rust code. soft-canonicalize, its dependencies (if it has any) and Rust’s standard library will be statically linked into the compiled Rust code that I will be distributing. This means that I will have to make sure that I’m complying with the licenses for all three of those things. Many open-source licenses require that you include the text of the license along with the content that you are distributing.
For soft-canonicalize and its dependencies, I’m planning on using cargo about. I’ll have cargo about generate an HTML file that contains all of the licenses for soft-canonicalize and its dependencies, and I’ll make sure that that HTML file is included in the Python wheel.
For Rust’s standard library, I don’t know what to do. I found this comment which seems useful:
I believe this issue is fixed now. As COPYRIGHT describes since #133461 was merged, distributions of Rust include a file COPYRIGHT-library.html that lists all licenses and copyright notices for the standard library (both in-tree files and crates.io dependencies). On my machine the file is located at $(rustc --print sysroot)/share/doc/rust/COPYRIGHT-library.html.
I would like to include COPYRIGHT-library.html in the Python wheel, but the phrase “On my machine” concerns me. Is there any guarantees about where COPYRIGHT-library.html will be located? Like, is there a function or a command that is guaranteed to give me the correct location for COPYRIGHT-library.html?
2 posts - 2 participants
Read full topic
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Why is f32/f64::sqrt not const? | 0 | 22.72 | 06-10-2026 |
| 2 | Rust abstractions for kernel sources | 0 | 4.62 | 08-10-2026 |
| 3 | If somebody tries to hot-patch an already-hot-patched function, how do they avoid conflicts? | 0 | 12.97 | 05-10-2026 |
| 4 | Porting a Slint UI Rust desktop application from Windows to macOS | 0 | 6.3 | 07-10-2026 |
| 5 | Why no Dependent Matrix Type? | 0 | 5.16 | 08-10-2026 |
| 6 | www/py-pywry - 0.6.2_23 | 0 | 27.65 | 02-10-2026 |
| 7 | Microsoft pushes back OneDrive max file path fix a month | 0 | 9.94 | 06-10-2026 |
| 8 | YouTube Video Quality Explained: Resolutions, Codecs, Bitrates, and How to Save Videos at the Quality You Want | 0 | 15.74 | 15-09-2026 |
| 9 | How to Download YouTube Videos in Multiple Languages: 2026 Guide | 0 | 25.27 | 09-09-2026 |