Putting the decker executable inside your project directory interprets the project directory as a development environment.

[salbeira]

If you want to sandbox decker as a first time user with a bit of technical know how you will be inclined - before installing the program - to run the executable in a sandbox directory.

If the decker executable is inside the directory it is run in it tries to interpret the directory as this github's development directory structure and tries to extract the resource packs from the resource directory - which does not exist outside of our development environment.

Therefore - for the user trying to sandbox the decker executable - it simply seems to not work at all.

The check that makes decker detect "am I running inside this repo's directory" needs to better detect this so you can run the decker executable inside a sandbox directory.

[mbotsch]

One of our colleagues just had this problem. @monofon can this be fixed?

[monofon]

Should be fixed now. Please close, if it actually is.

[salbeira]

Can confirm, with the current develop build I can put the resulting executable in a directory and run that executable from there without encountering an issue.

[salbeira]

@monofon Can you confirm that on your machine the ACTUAL development environment is detected? Seems that on my Windows machine the (cwd </> '.stack-work') `isPrefixOf` exePath is not detected and I can not launch a development run - turning it back into cwd `isPrefixOf` exePath allows me to use stack run -- --server in the dev environment again.

[monofon]

Yes, I can.

⟩ stack run -- decker --watch
# Running decker in: /Users/henriktramberend/workspace/decker/decker
This is a DEVELOPMENT RUN
...

Since this seems to be a Windows problem, maybe you can figure out a way to detect a development run on Windows.

[salbeira]

@monofon I think the culprit is the </>: On top of the Helper.js file we import System.FilePath.Posix which I think lets the compiler choose the "insert a / as a path seperator" implementation of the </> function. Changing the </> to a ++ System.FilePath.pathSeparator ++ fixes it.

Some printf debugging reveals:

exe: C:\Users\Hauer\Git\github\decker\.stack-work\install\536d28bd\bin\decker.exe
cwd: C:\Users\Hauer\Git\github\decker
wrk: C:\Users\Hauer\Git\github\decker/.stack-work

So the isPrefixOf fails (probably doing a string comp internally instead of doing it on a file path basis).

Can we change the import of System.FilePath.Posix to something more general or is something explicitly from the Posix module needed in Helper.js? Maybe this problem also appears somewhere else where we do a string compare on file paths.

Actually we do on different parts of a filepath already: The new whisper stuff checks for "does [...]/whisper/main exsist?" where on Windows you need to check "does [...]/whisper/main.exe exist?"

The other option is to change the "isPrefixOf" to something that explicitly compares filepaths.

[monofon]

Fixed in 3682ecb203e8c38a264de3512683aeb8e5354bc2.