Skip to content

Allow renaming the launcher without recompilation#195

Open
jdevera wants to merge 5 commits into
criteo:mainfrom
jdevera:runtime-app-name
Open

Allow renaming the launcher without recompilation#195
jdevera wants to merge 5 commits into
criteo:mainfrom
jdevera:runtime-app-name

Conversation

@jdevera
Copy link
Copy Markdown
Contributor

@jdevera jdevera commented Mar 25, 2026

Summary

Right now, if you want to run command-launcher under a different name (say vht instead of cdt), you have to recompile it. This PR makes it so you can just copy or rename the binary and it picks up the new name automatically.

This means you can build a single binary and use it for multiple launchers just by copying it. More importantly, anyone can grab the official release from the GitHub releases page and use it directly for their own launcher. No need to build from source at all.

How it works:

  • The app name is taken from the binary's real file path at startup (symlinks are resolved, so a symlink is just an alias: same name, same config)
  • If you copy the binary to a new name, it becomes a separate instance with its own config directory
  • The long display name (e.g. "Criteo Dev Toolkit") can be set in config via app_long_name, so you don't need to recompile for that either
  • If app_long_name isn't set, it falls back to the compiled-in default, so nothing changes for existing users

Example workflow:

cp cdt myapp
myapp config app_long_name "My Cool Launcher"
myapp help  # shows "My Cool Launcher" and "myapp" everywhere

Note on env var prefix: since a copied binary is a new identity, its env var prefix changes too (e.g. MYAPP_ instead of CDT_). This also means dropin scripts that hardcode a specific prefix won't see the right vars under a different binary name. The COLA_ prefixed vars (already exported by the launcher) work regardless of binary name.

Changes

  • main.go: resolve the binary path at startup to derive the app name
  • cmd/root.go: load config before creating the root command so we can read app_long_name
  • internal/config/settings.go: add app_long_name as a string config key
  • main_test.go: unit tests for the name resolution logic
  • test/integration/test-runtime-name.sh: integration tests for binary name, symlink, copy, and config override
  • test/integration/test-cmd-context.sh: updated FULL_COMMAND_NAME test — the old test copied the binary and relied on the copy sharing the original's env var prefix, which is no longer the case. The copy-based name behavior is now covered by test-runtime-name.sh instead.

Tests

  • Unit tests pass
  • Integration tests pass
  • New integration test covers: binary name detection, symlink resolution, copy gets own name, long name from config, original unaffected by copy's config
  • Smoke tested manually: build, copy, symlink, config override all work as expected

jdevera added 5 commits March 23, 2026 23:32
Resolve os.Args[0] through symlinks to get the real binary name at
runtime. Symlinks behave as aliases (same identity), while copies or
hard links produce a distinct app name and config directory.

The display long name can be overridden via the app_long_name config
key, falling back to the compiled-in default when unset.
…entity

The test-cmd-context test previously copied the cl binary to clcopy
and checked that CL_FULL_COMMAND_NAME reflected the new name. With
runtime app name resolution, a copied binary is now a separate instance
with its own env var prefix (CLCOPY_ instead of CL_), so the dropin
script's hardcoded $CL_FULL_COMMAND_NAME comes back empty.

The copy-based FULL_COMMAND_NAME behavior is already covered by the
new test-runtime-name integration test. This test now checks
FULL_COMMAND_NAME with the original cl binary, which still validates
that the env var is correctly set with group and without group.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant