bundled_pip_wheel_list[0]: unbound variable error if a broken Python install exists in app source
#1710
Assignees
Labels
Comments
edmorley
added a commit
that referenced
this issue
Dec 12, 2024
The Python stdlib bundles a copy of pip, which the buildpack uses to
bootstrap the real pip installation. This copy of pip should always
exist, and thus not finding it is treated as an internal error.
However, via Honeycomb I discovered one app that manages to hit this
case regardless, and when it does so, the error message is not the
"internal error" error message, but instead a Bash unbound variable
error like:
```
-----> Using Python 3.9.20 specified in .python-version
-----> Using cached install of Python 3.9.20
/tmp/buildpack/lib/utils.sh: line 33: bundled_pip_wheel_list[0]: unbound variable
```
I believe the reason for pip not being found in this case is that the
app source has a broken/EOL Python install committed to it (which
doesn't include the `ensurepip` module), which tricks the cache
restoration into thinking it can re-use the cache.
I will be adding an explicit warning/error for finding an existing
`.heroku/python/` directory in the app in a later PR, however, for now
this change:
(a) fixes the display of the internal error message,
(b) adds more debugging output to the error message so that I can
confirm my theory as to the root cause for this app.
Towards #1710.
GUS-W-17386432.
edmorley
added a commit
that referenced
this issue
Dec 12, 2024
The Python stdlib bundles a copy of pip, which the buildpack uses to
bootstrap the real pip installation. This copy of pip should always
exist, and thus not finding it is treated as an internal error.
However, via Honeycomb I discovered one app that manages to hit this
case regardless, and when it does so, the error message is not the
"internal error" error message, but instead a Bash unbound variable
error like:
```
-----> Using Python 3.9.20 specified in .python-version
-----> Using cached install of Python 3.9.20
/tmp/buildpack/lib/utils.sh: line 33: bundled_pip_wheel_list[0]: unbound variable
```
I believe the reason for pip not being found in this case is that the
app source has a broken/EOL Python install committed to it (which
doesn't include the `ensurepip` module), which tricks the cache
restoration into thinking it can re-use the cache.
I will be adding an explicit warning/error for finding an existing
`.heroku/python/` directory in the app in a later PR, however, for now
this change:
(a) fixes the display of the internal error message,
(b) adds more debugging output to the error message so that I can
confirm my theory as to the root cause for this app.
Towards #1710.
GUS-W-17386432.
edmorley
added a commit
that referenced
this issue
Dec 12, 2024
The Python stdlib bundles a copy of pip, which the buildpack uses to
bootstrap the real pip installation. This copy of pip should always
exist, and thus not finding it is treated as an internal error.
However, via Honeycomb I discovered one app that manages to hit this
case regardless, and when it does so, the error message is not the
"internal error" error message, but instead a Bash unbound variable
error like:
```
-----> Using Python 3.9.20 specified in .python-version
-----> Using cached install of Python 3.9.20
/tmp/buildpack/lib/utils.sh: line 33: bundled_pip_wheel_list[0]: unbound variable
```
My guess for why pip is not being found in this case is that the app's
Git repo may have a broken/EOL Python install committed to it (which
doesn't include the `ensurepip` module), which tricks the cache
restoration into thinking it can re-use the cache.
I will be adding an explicit warning/error for finding an existing
`.heroku/python/` directory in the app in a later PR, however, for now
this change:
(a) fixes the display of the internal error message,
(b) adds more debugging output to the error message so that I can
confirm my theory as to the root cause for this app.
Towards #1710.
GUS-W-17386432.
edmorley
added a commit
that referenced
this issue
Dec 13, 2024
- Adds a warning if the Python buildpack has been run multiple times in the same build. - Adds a warning if an existing `.heroku/python/` directory is found in the app source. - Improves the error message shown if the buildpack is used on an unsupported stack. Previously the build would fail with a curl download error depending on the availability of assets on S3. This scenario can only happen outside of Heroku, or in an old buildpack is used with a brand new stack (eg for Heroku-26). The two warnings are the first step towards #1704 and #1710, and will be turned into errors in January 2025. Towards #1704 and #1710. GUS-W-17386432. GUS-W-17309709.
edmorley
added a commit
that referenced
this issue
Dec 13, 2024
- Adds a warning if the Python buildpack has been run multiple times in the same build. - Adds a warning if an existing `.heroku/python/` directory is found in the app source. - Improves the error message shown if the buildpack is used on an unsupported stack. Previously the build would fail with a curl download error depending on the availability of assets on S3. This scenario can only happen outside of Heroku, or in an old buildpack is used with a brand new stack (eg for Heroku-26). The two warnings are the first step towards #1704 and #1710, and will be turned into errors in January 2025. Towards #1704 and #1710. GUS-W-17386432. GUS-W-17309709.
edmorley
added a commit
that referenced
this issue
Dec 13, 2024
- Adds a warning if the Python buildpack has been run multiple times in the same build. - Adds a warning if an existing `.heroku/python/` directory is found in the app source. - Improves the error message shown if the buildpack is used on an unsupported stack. Previously the build would fail with a curl download error depending on the availability of assets on S3. This scenario can only happen outside of Heroku, or in an old buildpack is used with a brand new stack (eg for Heroku-26). The two warnings are the first step towards #1704 and #1710, and will be turned into errors in January 2025. Towards #1704 and #1710. GUS-W-17386432. GUS-W-17309709.
edmorley
added a commit
that referenced
this issue
Dec 13, 2024
- Adds a warning if the Python buildpack has been run multiple times in the same build. - Adds a warning if an existing `.heroku/python/` directory is found in the app source. - Improves the error message shown if the buildpack is used on an unsupported stack. Previously the build would fail with a curl download error depending on the availability of assets on S3. This scenario can only happen outside of Heroku, or in an old buildpack is used with a brand new stack (eg for Heroku-26). The two warnings are the first step towards #1704 and #1710, and will be turned into errors in January 2025. Towards #1704 and #1710. GUS-W-17386432. GUS-W-17309709.
This was
linked to
pull requests
Dec 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Spotted via Honeycomb metrics and then reproduced locally...
If an app's source contains a file at
.heroku/python/bin/python, then the build currently fails with:Apps should not have any contents at
.heroku/python/(it's an internal location used by the buildpack), but I'm guessing perhaps some users may have downloaded an app's slug to rescue the source from an app years ago (from a Python version that doesn't haveensurepip?), and then extracted that directly into their Git repo without removing the Python binaries?GUS-W-17386432.
The text was updated successfully, but these errors were encountered: