Stop adding the current working directory to PATH
#1987
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently for historic reasons the buildpack adds the current working directory to `PATH`, due to adding an empty colon-delimited segment before the default Ubuntu `PATH`. This can cause errors if the app has a script/binary in its root directory that has the same name as a command the buildpack tries to run. For example, on Honeycomb I've seen internal errors when the buildpack attempts to locate the bundled pip, due to the `tail` command being run not being the command we expected: ``` -----> Installing pip 25.2, setuptools 70.3.0 and wheel 0.45.1 ./tail: line 1: heroku: command not found ! Internal Error: Unable to locate the Python stdlib's bundled pip. ``` Removing this customisation of `PATH` is a breaking change, but safer in the long run. Any apps that call a script or binary that's in the root directory of their app from `bin/pre_compile` or `bin/post_compile` hook (or any other subprocess called by the buildpack) will now need to do so via an explicit relative path. For example, use `./my_command` not `my_command` when calling the script/binary. This change doesn't affect: - app behaviour at run-time (only during the build) - apps that call scripts in a subdirectory (eg `foo/my_command`) - apps that already use a relative path for scripts in the app's root directory (eg `./my_command`) GUS-W-20472356.
dzuelke
approved these changes
Dec 8, 2025
Contributor
dzuelke
left a comment
dzuelke
left a comment
There was a problem hiding this comment.
I assume there is a test somewhere that triggers the invocation
Member
Author
This PR added a |
Member
Author
|
And the CWD during hook execution is tested via using a relative path here: |
Merged
Member
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Currently for historic reasons the buildpack adds the current working directory to
PATH, due to adding an empty colon-delimited segment before the default UbuntuPATH.This can cause errors if the app has a script/binary in its root directory that has the same name as a command the buildpack tries to run. For example, on Honeycomb I've seen internal errors when the buildpack attempts to locate the bundled pip, due to the
tailcommand being run not being the command we expected:Removing this customisation of
PATHis a breaking change, but safer in the long run (and also matches the Python CNB behaviour).Any apps that call a script or binary that's in the root directory of their app from
bin/pre_compileorbin/post_compilehook (or any other subprocess called by the buildpack) will now need to do so via an explicit relative path. For example, use./my_commandnotmy_commandwhen calling the script/binary.This change doesn't affect:
foo/my_command)./my_command)GUS-W-20472356.