How to set a core lib path other than ~/.moon/lib/core?

[bikallem]

Is there a way to specify moonbit core lib path to another arbitrary path? Perhaps an environment variable that I can set or a moon.mod.json setting?

At the moment it seems the moon build command expects the core to be in ~/.moon/lib/core?

My use case: I was currently hacking on core lib and did moon bundle. However, that made the vscode moonbit extension to fail/stop working.

It would be productive if a moonbit project can use certain core lib other than the one that the vscode moonbit extension expects.

[lijunchen]

You can set the core path using the MOON_CORE_OVERRIDE environment variable.

moon/crates/moonutil/src/moon_dir.rs

Lines 58 to 64 in fcf022d

	pub fn core() -> PathBuf {
	let env_var = std::env::var("MOON_CORE_OVERRIDE");
	if let Ok(path) = env_var {
	return PathBuf::from(path);
	}
	home().join("lib").join("core")
	}

Sorry for the lack of docs.

[chawyehsu]

While MOON_CORE_OVERRIDE could be used to override the core path for cli moon the build system, the LSP/vscode intellisense is currently hardcoded to load and use the core library from ~/.moon/lib/core (~ be $HOME or $USERPROFILE on Windows when MOON_HOME is undefined) in the function addCore of lsp-server.

I suggest the LSP changing to request and load the core lib from the cli moon, this will also make MOON_CORE_OVERRIDE have an effect on the vscode extension. chawyehsu/moonup#7 would also benefit from it. I don't suggest checking the MOON_CORE_OVERRIDE env var directly in the lsp extension since the lib path detection is still not very flexible in that way.

[bikallem]

intellisense is currently hardcoded to load and use the core library from ~/.moon/lib/core

At the moment, I am using MOON_HOME env var to package/use binary moonbit download package for NixOS/nix (https://github.com/bikallem/nix-dev/blob/main/pkgs/moonbit-core.nix). The moonbit cli works correctly, however, the only issue is the vscode plugin. It seems to want to always download the latest moonbit clis, rather than the one that is installed or the one MOON_HOME is pointing to. Could the vscode plugin behaviour be changed perhaps to respect the MOON_HOME env variable?

[bzy-debug]

vscode plugin respects the MOON_HOME env.

The problem is how to make vscode know the MOON_HOME env. In your case, it's probable that the env variable set in shell does not get into vscode GUI. Try something like this and see if it works:

MOON_HOME=/path/to/your/MOON_HOME code .