Removing long paths from the backend package?

[mwu-tow]

Hello,
Our backend package contains some file with long paths. For example:

enso\dist\2023.2.1-nightly.2023.11.23\lib\Standard\AWS\2023.2.1-nightly.2023.11.23\.enso\cache\ir\2023.2.1-nightly.2023.11.23\Standard\AWS\Database\Redshift\Internal\Redshift_Error_Mapper.ir

This when combined with various prefixes can yield paths exceeding the MAX_PATH limit on Windows. This already causes issues with NSIS installer on newer electron-builder versions.

I see some duplication in the path, namely:

1. The version number is repeated thrice: once for the engine, once for the library and once for the IR cache — if I read this correctly.
2. The Standard\AWS (the library name?) is repeated twice.

Do we really want to have such package structure or is it just a result of some historical reasons that serves no useful purpose?
If the latter, how quick of a fix would it be to change it? Also, how reliable would such a change be? How strong would be the guarantee that paths (e.g. due to nested module structure) won't get too long again anyway? (It is not about shortening these particular paths, it is about not encountering this again in the longer term.)

Do you (Engine Team) think that this can be reasonably addressed in the near future on your side or should I invest time in trying to fix installation scripts?

[JaroslavTulach]

There is an effort to remove .ir files from the distribution and keep only one .bindings file per Standard.* library. Tracked as #8323 & co. That would make the paths a little shorter without changing the naming scheme.

[mwu-tow]

There is an effort to remove .ir files from the distribution and keep only one .bindings file per Standard.* library. Tracked as #8323 & co. That would make the paths a little shorter without changing the naming scheme.

It will make things better but by a limited factor, the paths to the source files could still grow, I am afraid.
But I don't think there is any invincible fix available, as long as the source structure in file system corresponds to the language-level module structure. Well, perhaps putting sources in some kind of virtual filesystem — but then we'd be unable to access them in external text editors.

I am trying to replace the installer right now, so hopefully no workarounds will be necessary.

[JaroslavTulach]

putting sources in some kind of virtual filesystem

Yes, that's actually what I'd like to do. At least for std-base.

but then we'd be unable to access them in external text editors.

They'd be in a JAR/ZIP file and aren't modifiable anyway... e.g. maybe it is not that hard restrictions.