Comment out code that is causing project loading to fail on osx

[BastiaanOlij]

Commented out some code that I introduced that I think is the source of trouble for #11450

I haven't removed it at this point because I think we should discuss this further, so tagging @Calinou , @akien-mga and @reduz :)

Right now the OSX build makes the resource folder in the app bundle the current working folder so that if there is a datapack file in that folder, it will get loaded. That all works fine now.

I originally got thrown off by the get_resource_dir method as it made sense to have this return the resources path and it would open up the datapack from there. I only found out later there was a comment in the project loading code that this had become defunct and indeed, it only attempts to load a project.godot file from this location if specified. I left the code so we could have a discussion whether we want to change how this works.

What I didn't realise is that returning this value would cause the rest of the loading code to be skipped regardless of whether a project file was found. The result of this is that a tools build put inside of an app bundle won't load any projects!! (hence 11450)
Only when run directly things work as they should.

For now I've commented out the code so our tools build works again. Hope to catch you guys on IRC so we can decide whether to remove this all together or whether we do want to implement get_resource_dir the way I suggest and either make an exception for the tools build or remove the code that stops further loading if a project file can't be loaded from this location.

[akien-mga]

I don't think this logic is desirable at all, it means one can't run the binary without putting it in a correctly formed .app, right? Those paths are declared in the plist file, they should not be hardcoded in the binary.

What differs between the working code in 2.1 and the one in master?

[BastiaanOlij]

Hey Akien,

get_resource_dir is not implemented in 2.1 for OSX.

2.1 has the same code as we use here changing the working directory to the resource directory. As far as I know the plist is not involved in deciding what datapack is used. OSX forces us to use the resource folder, it is by all intent and purposes, a hardcoded location when deploying.

In 3 it broke because of the changes we made that the name of the datapack now takes the same name as the executable. That is what I fixed in my original PR. As I mentioned I got thrown off course with the get_resource_dir function. I can see merit of using it instead because I'm not a fan of relying on the cwd, but I'm just as happy removing that bit of code all together. The fix for the original problem was in correctly naming the datapack file.