Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
To clarify, this seems ok given that
go env GOPATH
enforces absolute pathThere 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.
abspath
is an idempotent function.Your concern is that, for some user, this logic would have worked before but will be broken after this change. Let's investigate that.
If the workflow was functional for the user before, we know that this
ifneq
evaluated tofalse
, or, that$( abspath $(REPO_ROOT))
was equal to the string on the right hand side of the expression.Therefore, we know that the value on the right hand side of the expression must already be in the output set of
abspath
.My change is to run that value through
abspath
again. Given thatabspath
is idempotent (running the function on an absolute path returns the input, since it's already an absolute path), it's provably correct here to applyabspath
once more - given some user for whom this logic works before my change, it is not possible for the addition of theabspath
call to change that.So, I'd re-word your comment: it does not seem ok, it must logically be ok, and it does not rely on go env GOPATH outputting an absolute path. It is provable regardless of the output that if this check passed before passing the second argument through abspath it must pass after.