Too long folder path or some weird constellation -> Conda environment creation failed

[RenNagasaki]

🔴 Please generate a diagnostics report and upload the "diagnostics.log" as this helps me understand your configuration.
I guess, that won't work since the install already bugs out in this case. It works flawlessly from a shorter and less special folder structure. I guess its either the folder structure depth or a combination with the . and - in the folder names. (Testing with: "DRIVE:\Test.awesome\alltalk_tts_0\atsetup.bat" worked without errors)

It's nothing blocking me at using alltalk, but it's some weird error which should be fixed or atleast known by you for some FAQ. 😄

Describe the bug
I'm currently writing an AIO Installer for multiple instances of Alltalk for my FFXIV Plugin so the End-User can kinda Plug & Play the whole system. While debugging my software and using the "atsetup.bat -silent" I get this error.

It tells me it can't find a specific file. (Error gets cut off depending on size of console window, doesn't get written into next line, bug aswell ? )

To Reproduce
Recreate this folder structure: "DRIVE:\Git-Repositories\Dalamud\Echokraut\Echokraut-Server\bin\Debug\net8.0-windows\alltalk_tts_0" and use atsetup.bat on a fresh git clone of alltalkbeta.

Text/logs
I doubt logs (more than already in screenshot) will help.

Desktop (please complete the following information):
AllTalk was updated: fresh git clone
Custom Python environment: no

[erew123]

HI @RenNagasaki Pretty sure you know I am away, so Im only replying in speculation (not been able to test anything). The only thing I see is the _0 being on the end of the alltalk_tts folder name. Is that something you have done? not sure why it has that or if that could cause an issue.. Just mentioining it as a thought

[RenNagasaki]

Hey @erew123, jeah all fine just wanted to document this bug i stumbled upon. No the 0 at the end shouldnt be the problem since it works flawlessly on shorter paths. F:\Test.awesome-stuff\alltalk_tts_0 works fine.
But yes it's something I did.

[erew123]

Humm, there has always been a 256 path character limit within windows since NT 3.1 and DOS. Although unc paths allow longer, batch files typically fall back to the legacy 256 path limit....it's just, the path you showed didn't look like 256.....but, there may be a path limit for any non English characters (Unicode characters) that visibly reduces the path,but underneath still uses the same amount of bytes....https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

Not sure off the top of my head without testing

[erew123]

@RenNagasaki I have tracked down an answer to this and its nothing you or I can do anything about. the long and short answer is that Conda (which builds the Python environment) has certain path limits set within it, details of which I cant get without looking through all the code of Conda.... which Im not going to attempt to do (not sure if you can).

This is kind of a legacy thing they keep in place and the reason is that packages installed underneath the conda environment may break the OS's path length, making it appear that Conda isnt working. Conda creates a few sub directories to kick off, which immediately reduces the path length for anything store in the Conda's environment e.g.

D:\environment_name\conda\Lib\site-packages

and in here is where it stores things installed with PIP. And of course, those packages may have a depth of ??? characters.

So lets assume you are on windows with a max path length of 256 characters. Conda during install will say "Im only allowing you a depth of 128 characters to install in, because the other 128 are being reserved for packages having their own depth requirements that may take up the other 128 characters.

So its a hard set Conda limitation. Sorry,