lix fails to detect system-installed haxe and neko

[Ashvith10]

Despite having Haxe and Neko provided by the system library, lix seems to be downloading Haxe and Neko.

System information

Kernel

$ uname -a
Linux wisteria 6.12.62 #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux

Distribution information

$ cat /etc/os-release 
NAME="Guix System"
ID=guix
PRETTY_NAME="Guix System"
LOGO=guix-icon
HOME_URL="https://guix.gnu.org"
DOCUMENTATION_URL="https://guix.gnu.org/en/manual"
SUPPORT_URL="https://guix.gnu.org/en/help"
BUG_REPORT_URL="https://lists.gnu.org/mailman/listinfo/bug-guix"

[back2dos]

That's "by design".

Lix does not expect a single global installation of haxe or neko, but rather multiple ones and the haxe and neko commands provided by lix pick the actual version based on configuration. It's not unlike for example nvm in that regard.

[Ashvith10]

@back2dos Unfortunately, the issue with it downloading binaries is that it makes assumption about the system being FHS-compatible.

[back2dos]

I'm not fully sure I understand what that means. Is lix downloading the wrong binaries? Or do you have a peculiar setup where you always have to build those binaries from source?

[Ashvith10]

I am on Guix, a distro that tries to be as close to bit-reproducibility. Guix, like NixOS, supports pinning and traversal to older package versions. One of the quirks of this property is that it does not follow the typical FHS layout, so the RPATH is no longer valid (/usr, /local, etc don't exist).

It is unfortunate, but I guess I'll have to use continue using haxelib in my case.

[back2dos]

Hmm. Tried to figure out what that really means, but I'm left wondering:

1. Do the binaries that lix downloads somehow rely on /usr, /local working? Where do you get your binaries from? Perhaps lix could be made to get the same ones.
2. Is the path that lix downloads into the problem? You can control that via the HAXESHIM_ROOT environment variable, if that's any help.

[lxea]

This also an issue on non glibc based distros, because lix downloads a binary that links with a different libc it fails to run. It'd be good to be able to set lix to use a system haxe installation as an alternative

[back2dos]

You can point .haxerc to a path, to unblock you. From there the question still remains how to turn this into a sensible user-facing thing. For example, lix could be given an escape hatch to resolve download locations through some user defined mechanism - most probably a cli tool that conforms to some particular interface.