-
Notifications
You must be signed in to change notification settings - Fork 487
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.
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
[direnv] Add basic .envrc.example #4747
Conversation
Signed-off-by: Zack Train <ztrain@uber.com>
My
|
I think I should add the
when the worktree is completely clean ( |
Signed-off-by: Zack Train <ztrain@uber.com>
Signed-off-by: Zack Train <ztrain@uber.com>
Signed-off-by: Zack Train <ztrain@uber.com>
Hey @zmt, thanks for opening this! I'm all about making contributor lives simpler though I'm a little hesitant introducing this to the repository, since it provides a place for changes to slip in that can run on developer machines without consent once the initial directory has been initially allow-listed. The makefile has targets that can be used to compile/build/test with the expected toolchain. Is there something that we get with this that we don't get with the Makefile? |
I find it quicker/better/faster when iterating to use |
Signed-off-by: Zack Train <ztrain@uber.com>
I triple-checked this after our discussion. You are correct about the sigh |
I guess if I remove the hook to |
Related: |
See potential direnv security improvements in direnv/direnv#556. Signed-off-by: Zack Train <ztrain@uber.com>
Signed-off-by: Zack Train <ztrain@uber.com>
.envrc.example
Outdated
@@ -0,0 +1,19 @@ | |||
toplevel="$(git rev-parse --show-toplevel)" | |||
|
|||
# ensure the pre-commit git hook is in place |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can omit setting up the hook now
.envrc.example
Outdated
pushd $toplevel >/dev/null && | ||
make go-check && | ||
popd >/dev/null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels a little cleaner to just use a subshell? (pushd and popd are verbose)
pushd $toplevel >/dev/null && | |
make go-check && | |
popd >/dev/null | |
(cd "$toplevel"; make go-check) |
Or, preferably, we can leverage the -C
option with make:
pushd $toplevel >/dev/null && | |
make go-check && | |
popd >/dev/null | |
make -C "$toplevel" go-check |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - I make extensive use of git -C
because I manage my home dir as a git repo, but it slipped my mind to do the same with make
.
.envrc.example
Outdated
machine="$(go env GOOS)-$(uname -m)" | ||
|
||
# export GOROOT and PATH for managed go sdk | ||
GOROOT="$toplevel/.build/$machine/go/$(cat .go-version)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is GOROOT required? This is typically deduced by where the go binary resides. If PATH causes the right go binary to be executed, then GOROOT shouldn't be required?
It might be useful however to unset GOROOT....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be useful however to unset GOROOT....
I started with unset, but I think I had an issue installing gopls in an unexpected spot, so I set it, but am perfectly happy to move it back to just unset it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have any details on the failure? If not, I'd rather go with the unset route until we do (FYI, our makefile unset's GOROOT)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am aware that the Makefile unsets GOROOT
. I think I just futzed about until the first thing worked for me, but didn't fully clean it up. I don't actually need GOROOT
. Updating.
.envrc.example
Outdated
|
||
# export GOROOT and PATH for managed go sdk | ||
GOROOT="$toplevel/.build/$machine/go/$(cat .go-version)" | ||
PATH="$GOROOT/bin:$PATH" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is already a makefile target that prints a modified path with the correct toolchain directory added (no need to repeat the same magic the makefile does to determine the path):
PATH="$GOROOT/bin:$PATH" | |
PATH="$(make -C "$toplevel" go-bin-path)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs --no-print-directory
to work.
.envrc.example
Outdated
# export GOROOT and PATH for managed go sdk | ||
GOROOT="$toplevel/.build/$machine/go/$(cat .go-version)" | ||
PATH="$GOROOT/bin:$PATH" | ||
export GOROOT PATH |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: PATH should already be exported.
Signed-off-by: Zack Train <ztrain@uber.com>
.envrc.example
Outdated
unset GOROOT | ||
make -C "$toplevel" go-check | ||
go_bin_path="$(make --no-print-directory -C $toplevel go-bin-path)" | ||
PATH="$go_bin_path:$PATH" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make go-bin-path
already appends the rest of the PATH so suffixing with $PATH shouldn't be required
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh! No wonder the path looked so long.
Signed-off-by: Zack Train <ztrain@uber.com>
.envrc.example
Outdated
# build and use the managed go sdk | ||
unset GOROOT | ||
make -C "$toplevel" go-check | ||
PATH="$(make --no-print-directory -C $toplevel go-bin-path)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should quote toplevel in case there are spaces to prevent word splitting
PATH="$(make --no-print-directory -C $toplevel go-bin-path)" | |
PATH="$(make --no-print-directory -C "$toplevel" go-bin-path)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got it in one spot but not the other 😞
Signed-off-by: Zack Train <ztrain@uber.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
\o/
Add a basic .envrc.example that will build the go sdk using the Makefile and setup the environment to use it so developers who use direnv can easily "automatically" use the managed go sdk. Update CONTRIBUTING.md to add a section describing the intended usage of direnv .envrc.example. Signed-off-by: Zack Train <ztrain@uber.com>
Add a basic .envrc.example that will build the go sdk using the Makefile and setup the environment to use it so developers who use direnv can easily "automatically" use the managed go sdk. Update CONTRIBUTING.md to add a section describing the intended usage of direnv .envrc.example. Signed-off-by: Zack Train <ztrain@uber.com>
Pull Request check list
Affected functionality
Add a basic
.envrc.example
that will build the go sdk using the Makefile andsetup the environment to use it so developers who use direnv
can easily "automatically" use the managed go sdk. Update CONTRIBUTING.md to
add a section describing the intended usage of
direnv
.envrc.example
.Description of change
While developing, it is good to use the same
go
tool as the make targetswhen running
go test
. This makes that easy for users ofdirenv
.Developers who don't use
direnv
or don't copy the example into place willsee no change.