pySPlisHSPlasH uses wrong directory for output, data and resources

[lukashof]

Hi 👋,

I am running pySPlisHSPlasH on Windows inside a venv. The installation seems to have worked. I do have the data and resources folders inside my venv. However, when I run the examples or splash, the output directory is set to my global Python installation and SPlisHSPlasH tries to load shaders or models from there as well and fails as the folders are missing.

I can of course set the output directory manually. But the only workaround I have found for the "missing" shaders and models, is to copy data and resources into my global python installation.

Did I make a mistake during the installation? I pointed to the Python executable inside the venv when compiling and built a wheel then ran the installation of pySPlisHSPlasH from inside my venv. Do I have to specify the executable again at this point?

This problem seems similar to #254 and the discussion under #151.

Best regards!

[digitalillusions]

Thanks for letting us know. I have not been aware of this issue actually, since I always use anaconda virtual environments, where this issue does not occur. I have also confirmed the behavior that you describe when using virtualenv.

It seems that the cause of the problem is the fact that virtualenv creates a symlink to the global python executable. Splishsplash gets the executable path here

SPlisHSPlasH/Utilities/FileSystem.h

Lines 215 to 229 in b7f8321

	static std::string getProgramPath()
	{
	char buffer[1000];
	#ifdef WIN32
	GetModuleFileName(NULL, buffer, 1000);
	#else
	char szTmp[32];
	sprintf(szTmp, "/proc/%d/exe", getpid());
	int bytes = std::min((int)readlink(szTmp, buffer, 1000), 999);
	buffer[bytes] = '\0';
	#endif
	std::string::size_type pos = std::string(buffer).find_last_of("\\/");
	return std::string(buffer).substr(0, pos);
	}

which apparently resolves through the symlink to the original executable and then tries to load all assets relative to this path. I'm not exactly sure how to prevent this behavior, since this is also tied to how the OS handles executables. I'll update this discussion if I find a solution.

[lukashof]

I see, maybe it is a Windows-only problem then. So far, I haven't tried it on a Linux system. I guess I'll try that or with Conda again.

This might be obvious to you already, but I found that GetModuleFileName returns the path to my global interpreter. It is used here:

SPlisHSPlasH/Utilities/FileSystem.h

Lines 215 to 219 in dc2f63f

	static std::string getProgramPath()
	{
	char buffer[1000];
	#ifdef WIN32
	GetModuleFileName(NULL, buffer, 1000);

[digitalillusions]

It could be that I didn't catch the problem then, or that --copies doesn't actually copy the interpreter and necessary DLLs to the venv directory on windows. Again, I unfortunately cannot test myself this at the moment. Can you check if the venv/bin directory actually contains its own non-shortcutted version of python?

[lukashof]

The folder structure on Windows seems to be a bit different, so there is no bin. However, there is an executable inside the Scripts folder.

I can see no difference running the command with or without the --copies option, but it will throw an error when run with --symlinks.

[lukashof]

I just realized, that getProgramPath was probably intended to return the path to bin containing the SPHSimulator.exe. Or am I mistaken? In that case it wouldn't be an issue with venv at all.

[lukashof]

I have now tried this on a Linux system and the resources are indeed picked up from inside the venv-folder.

Regarding Windows, it might be an option to get the path to the interpreter during building instead of using GetModuleFileName if the bindings are used. Then again, it might be more intuitive to have the resources and outputs somewhere in the project folder or in the build directory. That seems more intuitive to me. Or am I missing something?