Skip to content

DefaultPackagePathToName: fall back to a path-based guess when go isn't available#29

Open
c-tonneslan wants to merge 1 commit into
hexops:mainfrom
c-tonneslan:fix/packagepath-fallback-without-go
Open

DefaultPackagePathToName: fall back to a path-based guess when go isn't available#29
c-tonneslan wants to merge 1 commit into
hexops:mainfrom
c-tonneslan:fix/packagepath-fallback-without-go

Conversation

@c-tonneslan
Copy link
Copy Markdown

Closes #18.

packages.Load shells out to the go binary, so in environments where that's absent (WebAssembly, the Go Playground) String() returned go command required, not found. When packages.Load fails or returns no name, derive the package name from the last non-version segment of the import path. That isn't always the real name but it's good enough to render literals without forcing every caller to set a custom PackagePathToName.

…'t available

Closes hexops#18.

packages.Load shells out to the go binary, so in environments where
that's absent (WebAssembly, the Go Playground) String() returned 'go
command required, not found'. When packages.Load fails or returns no
name, derive the package name from the last non-version segment of
the import path. That's not always the real name but it's good enough
to render literals without forcing every caller to set a custom
PackagePathToName.

Signed-off-by: Charlie Tonneslan <cst0520@gmail.com>
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.

String function is not viable in environments where executable go is unavailable

1 participant