vendor mode creates paths that are too long for windows

peakschris commented 3 weeks ago

Description of the bug:

After vendoring a bazel install, some zip file paths are above the windows path length limit, and refuse to delete. I wonder if we could choose shorter names for the zip files to avoid this. There only appears to be one zip file in each directory.

The zipfile clearly exists:

D:\workdir>dir workspace\vendor6\vendor\_main~main_extension~nuget.runtime.osx.10.10-x64.runtime.native.system.security.cryptography.openssl.v4.3.3
 Volume in drive D is Data
 Volume Serial Number is 982B-CBB1

 Directory of D:\workdir\workspace\vendor6\vendor\_main~main_extension~nuget.runtime.osx.10.10-x64.runtime.native.system.security.cryptography.openssl.v4.3.3

05/11/2024  05:33 AM    <DIR>          .
05/11/2024  05:33 AM    <DIR>          ..
02/22/2024  08:46 AM            47,013 _main~main_extension~nuget.runtime.osx.10.10-x64.runtime.native.system.security.cryptography.openssl.v4.3.3.zip
               1 File(s)         47,013 bytes
               2 Dir(s)  33,448,583,168 bytes free

But windows refuses to delete it:

D:\units>del workspace\vendor6\vendor\_main~main_extension~nuget.runtime.osx.10.10-x64.runtime.native.system.security.cryptography.openssl.v4.3.3\_main~main_extension~nuget.runtime.osx.10.10-x64.runtime.native.system.security.cryptography.openssl.v4.3.3.zip
The system cannot find the path specified.

I know, this shouldn't be needed, but it's windows and seems like it may never be fixed (rollseyes)

There are ways to delete these directories, but they are ridiculously hacky.

Which category does this issue belong to?

External Dependency

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

vendor a directory with some long/nested module names on windows try to delete it with rmdir /s /q

Which operating system are you running Bazel on?

windows

What is the output of `bazel info release`?

7.2.0rc2

If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

No response

What's the output of `git remote get-url origin; git rev-parse HEAD` ?

No response

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

meteorcloudy commented 3 weeks ago

There is really little we can do in Bazel. The only way around is to choose a shorter name for the repository, files or the vendor path.

peakschris commented 1 week ago

@meteorcloudy how about:

instead of this: vendor\_main~main_extension~nuget.runtime.osx.10.10-x64.runtime.native.system.security.cryptography.openssl.v4.3.3\_main~main_extension~nuget.runtime.osx.10.10-x64.runtime.native.system.security.cryptography.openssl.v4.3.3.zip

the zip is named: vendor\_main~main_extension~nuget.runtime.osx.10.10-x64.runtime.native.system.security.cryptography.openssl.v4.3.3\vendor.zip

meteorcloudy commented 1 week ago

@peakschris Can you elaborate more? The file path is determined by the repo itself. I don't think vendor mode can arbitrarily change the path?

bazelbuild / bazel