Runtime API to check whether in self-contained exe

[DerZade]

I couldn't find a runtime API to check whether the current code is running inside a self-contained exe.

This would make it easy to distinguish between the "production" (compiled) version and testing via deno run.

I was thinking about something like Deno.standalone or maybe something more descriptive like Deno.selfContainedExe.

[dsherret]

Would you be able to provide some use cases for this suggestion? There might be alternatives.

[DerZade]

Would you be able to provide some use cases for this suggestion? There might be alternatives.

I want to have a data directory at a relative path to the executable (or the main module when not compiled).

I can't use Deno.mainModule as a base, because that doesn't work in self contained executables (it includes the path of the main module at build time) and I can't use Deno.execPath, because that returns the deno exe, when not compiled.

Also the relative path differs a bit between compiled and not compiled. For compiled it is ./data (relative to the executable) otherwise it's ../data (relative to the main module)

---

This is my specific use case, but I bet there are more use cases, which would benefit from such an API.

[jsejcksn]

@DerZade Not a solution, but here's a potential workaround if you're in control of compiling the binary:

You can switch on the presence of a specific CLI argument to make the determination, and embed that argument into the compiled binary:

example.ts:

import * as path from "https://deno.land/[email protected]/path/mod.ts";

const isCompiled = Deno.args.includes("--is_compiled_binary");

const programPath = isCompiled
  ? Deno.execPath()
  : path.fromFileUrl(Deno.mainModule);

const programDir = path.dirname(programPath);

console.log({
  isCompiled,
  programDir,
  programPath,
});

gh-issue-15996 % deno --version                              
deno 1.26.0 (release, x86_64-apple-darwin)
v8 10.7.193.3
typescript 4.8.3

gh-issue-15996 % deno run --allow-read --no-prompt example.ts
{
  isCompiled: false,
  programDir: "/Users/deno/gh-issue-15996",
  programPath: "/Users/deno/gh-issue-15996/example.ts"
}

gh-issue-15996 % mkdir binary_dir

gh-issue-15996 % deno compile --output=binary_dir/example --allow-read --no-prompt example.ts --is_compiled_binary
Compile file:///Users/deno/gh-issue-15996/example.ts
Emit binary_dir/example

gh-issue-15996 % ./binary_dir/example 
{
  isCompiled: true,
  programDir: "/Users/deno/gh-issue-15996/binary_dir",
  programPath: "/Users/deno/gh-issue-15996/binary_dir/example"
}

Of course, you'll have to account for this potential extra argument if your program already accepts other arguments — and if you're concerned about the target argument being inadvertently used with the not-compiled script (a false positive), just use something unguessable like a UUID in place of the one I used in the example above.

[DerZade]

@jsejcksn I also thought about that workaround and we will probably use something similar in our product, but I still think a actual Deno-API would be nice.

[mxcl]

What I don’t like about the suggestion is the user could supply this argument themselves to deno run. However that's less of an issue since I plan to distribute the binary and only expect users to run the sources when hacking on them.

Also I would feel better if the code I'm trying to change is actively not included in the final binaries, which I would expect to happen due to dead code removal if there was a static API for the “you're being compiled” condition.

[K0IN]

Hei, is there any update on this (the PR seems to be stale, last update a year ago) I would really like this feature as a workaround (if the behaviour is intended) for my issue: #24318