Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support for explicitly specifying node entrypoint location #3889

Closed
1 of 2 tasks
dastbe opened this issue Dec 22, 2022 · 4 comments
Closed
1 of 2 tasks

Add support for explicitly specifying node entrypoint location #3889

dastbe opened this issue Dec 22, 2022 · 4 comments
Labels
feature-request A feature should be added or improved. p2

Comments

@dastbe
Copy link
Contributor

dastbe commented Dec 22, 2022 •
edited
Loading

Describe the feature

Similar to how one can specify the runtime via JSII_RUNTIME, there should also be support for providing an explicit location for the node entrypoint with fallback to searching the path.

Use Case

For my particular use case, I'm writing bazel rules to handle executing cdk apps written in arbitrary languages. In this case, manipulating the path to ensure the correct node entrypoint is present and has the correct priority is problematic and non-standard across language_binary targets. By comparison, having an explicit environment variable for setting the node entrypoint would be straightforward to support.

Proposed Solution

Add a JSII_NODE environment variable option to specify the exact location of the node entrypoint. if unset, fallback to existing behavior of environment lookup.

Other Information

No response

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change

CDK version used

2.55.0

Environment details (OS name and version, etc.)

mac/linux
@dastbe dastbe added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Dec 22, 2022
@dastbe dastbe mentioned this issue Dec 23, 2022
Merged
@dastbe
Copy link
Contributor Author

dastbe commented Dec 23, 2022

I've created #3890 to demonstrate how this will work for go. If you're down with this approach I can implement the remaining runtimes.

@RomainMuller
Copy link
Contributor

Is this not the same as ensuring the "correct" node is the 1st in $PATH?

@dastbe
Copy link
Contributor Author

dastbe commented Jan 1, 2023

In normal cases, yeah. However, with bazel (and go) there are complexities

  1. bazel prefers away from putting things on the path. You can work around this by using the run_shell command and constructing the path as part of the shell script, but including arbitrary binaries (i.e. a go cdk app, a js cdk app, a c# cdk app, etc.) becomes more difficult as you need to handle more environment setup compared to the more straightforward run command for a binary target. Since this environment setup can vary by the binary type, you possibly have to do incremental work for every cdk language.
  2. bazel prefers using relative paths as it uses a combination of symlinks and sandbox directories depending on the platform. go in particular no longer supports relative path lookups. You can again hack around this as part of a run_shell command, but see above why run_shell is complicated to use when you have multiple kinds of binaries you can support.

dastbe added a commit to dastbe/rules_cdk that referenced this issue Jan 1, 2023
@dastbe
feat: support arbitrary CDK languages
774be02 
While aws/jsii#3889 would be the best possible
outcome for supporting arbitrary languages, this hacks around the
current implementation looking up the node bin from the path, as well as
hacking around go's refusal to look up binaries that are in a relative
directory.
@dastbe dastbe mentioned this issue Jan 1, 2023
Merged
dastbe added a commit to dastbe/rules_cdk that referenced this issue Jan 1, 2023
@dastbe
feat: support arbitrary CDK languages
6aadf41 
While aws/jsii#3889 would be the best possible
outcome for supporting arbitrary languages, this hacks around the
current implementation looking up the node bin from the path, as well as
hacking around go's refusal to look up binaries that are in a relative
directory.
mergify bot pushed a commit to dastbe/rules_cdk that referenced this issue Jan 1, 2023
@dastbe
feat: support arbitrary CDK languages (#44)
4a1425e 
While aws/jsii#3889 would be the best possible
outcome for supporting arbitrary languages, this hacks around the
current implementation looking up the node bin from the path, as well as
hacking around go's refusal to look up binaries that are in a relative
directory.
mergify bot pushed a commit that referenced this issue Feb 16, 2023
@dastbe
feat(go): add JSII_NODE to override node entrypoint (#3890)
357562a 
By default, jsii-go will lookup the node entrypoint from the PATH. This allows users to override with a specific node entrypoint via the JSII_NODE environment variable.

issue: #3889

---

By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license].

[Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
@mrgrain mrgrain added p2 and removed needs-triage This issue or PR still needs to be triaged. labels Apr 9, 2024
@mrgrain mrgrain closed this as completed Apr 9, 2024
@github-actions GitHub Actions
Copy link
Contributor

github-actions bot commented Apr 9, 2024

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature-request A feature should be added or improved. p2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mrgrain @RomainMuller @dastbe