This repository has been archived by the owner on Dec 31, 2021. It is now read-only.
Update python buildpack #1
Open
Conversation
This file contains 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
Updates Pipenv from 2020.11.15 to: - 2022.4.8 for Python 3.6 - 2023.2.4 for Python 3.7+ Release notes: https://github.com/pypa/pipenv/blob/main/CHANGELOG.rst#pipenv-202324-2023-02-04 Full changes: pypa/pipenv@v2020.11.15...v2023.2.4 Closes #1403. GUS-W-9348641.
Previously if a new app did not specify a Python version via a `runtime.txt` file or the appropriate `Pipfile` config option, then the buildpack would default to the latest Python 3.10 release (currently Python 3.10.10). Now the buildpack will use the latest Python 3.11 release (currently Python 3.11.2). This does not affect: * apps that specify an explicit Python version * existing apps that have already had a build using the previous default version (since that version is remembered from one build to the next, via the "sticky versions" feature). Use-cases involving new apps that aren't compatible with Python 3.11 will now need to specify Python 3.10 explicitly: https://devcenter.heroku.com/articles/python-support#specifying-a-python-version However most apps should be compatible, since Python 3.11 was released several months ago (2022-10-24), does not contain significant breaking changes over Python 3.10, and has been happily used by the python-getting-started project since 2022-10-25. GUS-W-12345720.
Since otherwise it prevents Hatchet from cleaning up apps. (Further improvements to Hatchet and end of CI run setup will happen soon, however, for now this is better than nothing.)
Updates the `wheel` packaging tool from 0.37.1 to 0.38.4 when using Python 3.7+. The version is unchanged for Python 3.6 since the newer wheel version has dropped support for it. See: https://wheel.readthedocs.io/en/stable/news.html pypa/wheel@0.37.1...0.38.4 GUS-W-12030292.
Since: - It has been end of life upstream since 2021-12-23, so is no longer receiving security updates. - The buildpack has been warning about its end of life in the build log output since 2022-08-17. - The upgrade from Python 3.6 to Python 3.7+ in many cases requires no changes to an application at all, or else some small dependency updates (compared to say the upgrade from Python 2 to 3). - It is already not available on Heroku-22 (due to it being incompatible with OpenSSL 3), so apps will need to switch eventually. - Any apps that must stay on Python 3.6 short term, can pin to the previous buildpack version as a stop-gap. GUS-W-12345793.
And also remove a Python 3.6 remnant leftover from #1415.
Bumps [rspec-core](https://github.com/rspec/rspec-core) from 3.12.0 to 3.12.1. - [Release notes](https://github.com/rspec/rspec-core/releases) - [Changelog](https://github.com/rspec/rspec-core/blob/main/Changelog.md) - [Commits](rspec/rspec-core@v3.12.0...v3.12.1) --- updated-dependencies: - dependency-name: rspec-core dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [rubocop](https://github.com/rubocop/rubocop) from 1.44.1 to 1.46.0. - [Release notes](https://github.com/rubocop/rubocop/releases) - [Changelog](https://github.com/rubocop/rubocop/blob/master/CHANGELOG.md) - [Commits](rubocop/rubocop@v1.44.1...v1.46.0) --- updated-dependencies: - dependency-name: rubocop dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [rubocop](https://github.com/rubocop/rubocop) from 1.46.0 to 1.47.0. - [Release notes](https://github.com/rubocop/rubocop/releases) - [Changelog](https://github.com/rubocop/rubocop/blob/master/CHANGELOG.md) - [Commits](rubocop/rubocop@v1.46.0...v1.47.0) --- updated-dependencies: - dependency-name: rubocop dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Bump heroku_hatchet from 7.4.0 to 8.0.1 Bumps [heroku_hatchet](https://github.com/heroku/hatchet) from 7.4.0 to 8.0.1. - [Release notes](https://github.com/heroku/hatchet/releases) - [Changelog](https://github.com/heroku/hatchet/blob/main/CHANGELOG.md) - [Commits](heroku/hatchet@v7.4.0...v8.0.1) --- updated-dependencies: - dependency-name: heroku_hatchet dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]> * Remove HATCHET_BUILDPACK_BRANCH workaround --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Ed Morley <[email protected]>
As of Hatchet v8.x, Hatchet now: - Removes the apps it creates after each test runs, rather than only enabling maintenance mode. This occurs even if an individual test fails. - Cleans up older apps iff it runs into the app limit. (This is only done when the app limit is hit, in order to prevent hundreds of unnecessary API requests, when test concurrency is high.) However, leftover apps can still occur in the following cases: - The GitHub Actions run is cancelled, or aborts in a non-clean way. - If a Hatchet bug (or a mis-use of Hatchet by the tests) cause Hatchet to exit non-cleanly. - If there is a platform incident causing the Heroku API to not be available. Therefore, this scheduled cleanup job has been added to catch any such leftover apps. It runs daily at 6am UTC, and can also be triggered manually via the GitHub dashboard. The cleanup job only deletes apps older than 10 minutes, so that it doesn't break any in progress CI jobs. GUS-W-12629391.
Update from Ruby 2.7 to 3.1 and bump dependencies, given Ruby 2.7
EOLs soon. Ruby 3.1 had to be used since Hatchet doesn't yet support
Ruby 3.2.
After upgrading, a number of new Rubocop fixes are needed, to resolve eg:
```
spec/hatchet/pip_spec.rb:92:88: C: [Correctable] Style/HashSyntax: Omit the hash value.
let(:app) { Hatchet::Runner.new('spec/fixtures/requirements_editable', buildpacks: buildpacks) }
```
GUS-W-12670465.
pipenv 2023.2.18 raised its minimum setuptools version to 67.x, which is newer than the setuptools version the buildpack pins to. This succeeds on the first build, however, for cached rebuilds then fails due to pip's version resolver not allowing overriding already-installed dependency versions when resolving version conflicts. A new testcase has been added for pipenv caching (caching was already extensively tested when using pip, just not when using pipenv). Resolves: ``` remote: -----> Installing pip 23.0.1, setuptools 63.4.3 and wheel 0.38.4 remote: ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. remote: pipenv 2023.2.18 requires setuptools>=67.0.0, but you have setuptools 63.4.3 which is incompatible. ``` Longer term we will update to newer setuptools ourselves (once the dust settles on the many breaking changes introduced in newer setuptools versions), and hopefully newer pipenv will also relax its minimum setuptools version slightly. GUS-W-12670935.
Bumps [rubocop](https://github.com/rubocop/rubocop) from 1.48.0 to 1.48.1. - [Release notes](https://github.com/rubocop/rubocop/releases) - [Changelog](https://github.com/rubocop/rubocop/blob/master/CHANGELOG.md) - [Commits](rubocop/rubocop@v1.48.0...v1.48.1) --- updated-dependencies: - dependency-name: rubocop dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Builds are now performed on GitHub Actions (which supports IP allowlisting), and can be triggered via the dispatch job workflow. * The build process no longer uses the legacy bob-builder tool. * The identical and thus redundant per-version scripts have been removed. * The per-stack Dockerfiles have been consolidated. GUS-W-12964868.
https://blog.python.org/2023/04/its-time-for-another-set-of-python.html https://docs.python.org/release/3.10.11/whatsnew/changelog.html#python-3-10-11-final https://docs.python.org/release/3.11.3/whatsnew/changelog.html#python-3-11-3 The binaries were built using GitHub Actions: https://github.com/heroku/heroku-buildpack-python/actions/runs/4623261574 https://github.com/heroku/heroku-buildpack-python/actions/runs/4623259900 GUS-W-12345405. GUS-W-12345408.
Bumps [rubocop](https://github.com/rubocop/rubocop) from 1.48.1 to 1.49.0. - [Release notes](https://github.com/rubocop/rubocop/releases) - [Changelog](https://github.com/rubocop/rubocop/blob/master/CHANGELOG.md) - [Commits](rubocop/rubocop@v1.48.1...v1.49.0) --- updated-dependencies: - dependency-name: rubocop dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
- Updated setuptools from 67.5.0 to 67.6.1. - Updated wheel from 0.38.4 to 0.40.0. Of note, the setuptools introduces more strict parsing of version specifiers (some invalid but previously accepted package version strings will now be rejected by setuptools, if they don't conform to PEP 440). If errors are encountered installing packages due to invalid package version strings, then users will need to update to fixed versions of those packages, or else pin to a previous buildpack release until the affected package is fixed. For more information, see: - https://setuptools.pypa.io/en/stable/history.html#v66-0-0 - https://peps.python.org/pep-0440/ In addition, changes have been made to the way setuptools handles editable installs, that may affect some projects using editable mode (`-e`) depending on the project layout. See: - https://setuptools.pypa.io/en/stable/history.html#v64-0-0 - https://setuptools.pypa.io/en/stable/userguide/development_mode.html Full changelogs: https://setuptools.pypa.io/en/stable/history.html#v67-6-1 https://wheel.readthedocs.io/en/stable/news.html GUS-W-12346556. GUS-W-13011106.
To support environments where it takes longer than 5 seconds to establish the HTTPS connection (such as Dokku). Fixes #1436. GUS-W-13013203.
Since it was released today, rather than yesterday.
Previously the buildpack downloaded a pip wheel from S3 in order to bootstrap the pip/setuptools/wheel installation. Newer Python versions (Python 3.4+) bundle a pip wheel as part of the `ensurepip` module, which we can use instead of having to perform this download now that we've dropped support for Python 2. This approach: - improves performance/reliability of repeat builds, since it saves having to download the pip wheel each time - reduces the toil of performing pip updates, since we no longer need to upload new pip versions to the S3 bucket each time - matches the approach already used in the new Python CNB. GUS-W-13111316.
Currently the buildpack will use whichever package manager it finds first, if the files of multiple package managers are found. This occasionally results in support tickets where the user believes the build to not be installing dependencies correctly, when in fact they are adding dependencies to the wrong package manager file. As such, we want to make the presence of multiple package manager files an error, but first we should add a warning so it's not a surprise. (Plus with the recent Poetry support addition, there will be apps using the third party Poetry buildpack that have both a `poetry.lock` and the generated `requirements.txt` until they remove the third-party buildpack.) Towards #1691. GUS-W-17167927.
Improves the build log output, error messages and buildpack failure metrics for the NLTK downloader feature, and adds a test for the app having an invalid `nltk.txt` (since previously only the successful cases were tested). This should be the last failure type seen in the wild that doesn't emit a `failure_reason` metric. GUS-W-8059892.
Since the `/latest/` URLs are for the unreleased development version, rather than the latest stable release.
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
Using Pipenv without a lockfile can result in nondeterministic package installs, and so for some years if `Pipfile.lock` is missing we've emitted a recommendation in the build log to add it. In addition, Pipenv has also since deprecated the `--skip-lockfile` feature upstream. As such, we'd like to sunset support for using Pipenv without a lockfile, but first we should make the existing warning more explicit and include instructions on how to generate a lockfile. GUS-W-17201692.
When `python -m venv` is run, after creating the virtual environment it invokes `ensurepip` to install pip. The `ensurepip` module in older Python versions didn't correctly run its Python subprocesses in isolated mode, meaning that the working directory is added to `sys.path`. This can cause issues if the app's build directory contains files/directories that shadow expected package names (such as a `brotli` directory). For example: ``` -----> Installing Poetry 1.8.4 Error: Command '['/tmp/codon/tmp/cache/.heroku/python-poetry/venv/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1. ! Internal Error: Unable to create virtual environment for Poetry. ! ! The 'python -m venv' command to create a virtual environment did ! not exit successfully. ! ! See the log output above for more information. ``` The best fix is for apps to upgrade to newer Python patch versions (3.8.14+, 3.9.14+, 3.10.6+), since they include the upstream `ensurepip` fix as well as many other bug and security fixes. However, to ensure venv creation still works on these older Python versions, as a workaround we can run the `python -m venv` command from a different working directory (as an alternative to isolated mode). Fixes #1697. GUS-W-17215816.
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
…1709) * Bump the ruby-dependencies group across 1 directory with 2 updates Bumps the ruby-dependencies group with 2 updates in the / directory: [logger](https://github.com/ruby/logger) and [rubocop](https://github.com/rubocop/rubocop). Updates `logger` from 1.6.1 to 1.6.2 - [Release notes](https://github.com/ruby/logger/releases) - [Commits](ruby/logger@v1.6.1...v1.6.2) Updates `rubocop` from 1.68.0 to 1.69.1 - [Release notes](https://github.com/rubocop/rubocop/releases) - [Changelog](https://github.com/rubocop/rubocop/blob/master/CHANGELOG.md) - [Commits](rubocop/rubocop@v1.68.0...v1.69.1) --- updated-dependencies: - dependency-name: logger dependency-type: direct:development update-type: version-update:semver-patch dependency-group: ruby-dependencies - dependency-name: rubocop dependency-type: direct:development update-type: version-update:semver-minor dependency-group: ruby-dependencies ... Signed-off-by: dependabot[bot] <[email protected]> * bundle update --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Ed Morley <[email protected]>
* Bump pip from 24.0 to 24.3.1 Bumps [pip](https://github.com/pypa/pip) from 24.0 to 24.3.1. - [Changelog](https://github.com/pypa/pip/blob/main/NEWS.rst) - [Commits](pypa/pip@24.0...24.3.1) --- updated-dependencies: - dependency-name: pip dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> * Update tests + comments * Add changelog entry --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Ed Morley <[email protected]>
* Bump wheel from 0.44.0 to 0.45.1 Bumps [wheel](https://github.com/pypa/wheel) from 0.44.0 to 0.45.1. - [Release notes](https://github.com/pypa/wheel/releases) - [Changelog](https://github.com/pypa/wheel/blob/main/docs/news.rst) - [Commits](pypa/wheel@0.44.0...0.45.1) --- updated-dependencies: - dependency-name: wheel dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> * Add changelog entry --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Ed Morley <[email protected]>
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
…1712) Release announcement: https://blog.python.org/2024/12/python-3131-3128-31111-31016-and-3921.html Changelog: https://docs.python.org/3.13/whatsnew/changelog.html#python-3-13-1-final https://docs.python.org/3.12/whatsnew/changelog.html#python-3-12-8-final https://docs.python.org/release/3.11.11/whatsnew/changelog.html#python-3-11-11-final https://docs.python.org/release/3.10.16/whatsnew/changelog.html#python-3-10-16-final https://docs.python.org/release/3.9.21/whatsnew/changelog.html#python-3-9-21-final Binary builds: https://github.com/heroku/heroku-buildpack-python/actions/runs/12159159015 https://github.com/heroku/heroku-buildpack-python/actions/runs/12159160169 https://github.com/heroku/heroku-buildpack-python/actions/runs/12159161685 https://github.com/heroku/heroku-buildpack-python/actions/runs/12162379421 https://github.com/heroku/heroku-buildpack-python/actions/runs/12159164423 GUS-W-14846803. GUS-W-17350155. GUS-W-17367730.
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
For apps that do not specify an explicit Python version (e.g.: via a `.python-version` or `runtime.txt` file), the buildpack uses a curated default version for the first build of the app. Then for subsequent builds of the app, the buildpack selects a Python version based on the version found in the build cache, so that the version used for the app doesn't change in a breaking way over time as the buildpack's own default version changes. This feature is referred to as "version pinning" and/or "sticky versions". The existing implementation of this feature pinned the version to the full Python version (e.g. `3.13.0`), meaning that the app would always use that exact Python version, even when newer backwards-compatible patch releases (such as `3.13.1`) became available over time. Now that we have Python major version -> latest patch version resolution support (as of #1658) and improved build output around cache invalidation reasons (as of #1679), we can switch to instead only pinning to the major Python version (e.g. `3.13`). This allows apps that do not specify a Python version to pick up any bug and security fixes for their major Python version the next time the app is built, whilst still keeping the compatibility properties of version pinning. Longer term, the plan is to deprecate/sunset version pinning entirely (since it leads to confusing UX / lack of parity between multiple apps deployed from the same codebase at different times, e.g. review apps), and the Python CNB has already dropped support for it. However, that will be a breaking change for the classic buildpack, so out of scope for now. GUS-W-17384879.
Previously if a new app did not specify a Python version (e.g. via a `.python-version` file), then the buildpack would default to the latest Python 3.12 release. Now the buildpack will use the latest Python 3.13 release. This does not affect: * apps that specify an explicit Python version * existing apps that have already had a build using the previous default version (since that version is remembered from one build to the next, via the "version pinning" / "sticky versions" feature). Use-cases involving new apps that aren't compatible with Python 3.13 will now need to specify Python 3.12 explicitly: https://devcenter.heroku.com/articles/python-support#specify-a-python-version However most apps should be compatible, since Python 3.13 was released a couple of months ago (2024-10-07), does not contain significant breaking changes over Python 3.12, and has been happily used by the python-getting-started project since 2024-10-10. See: https://docs.python.org/3.13/whatsnew/3.13.html GUS-W-14846972.
* Bump poetry from 1.8.4 to 1.8.5 Bumps [poetry](https://github.com/python-poetry/poetry) from 1.8.4 to 1.8.5. - [Release notes](https://github.com/python-poetry/poetry/releases) - [Changelog](https://github.com/python-poetry/poetry/blob/1.8.5/CHANGELOG.md) - [Commits](python-poetry/poetry@1.8.4...1.8.5) --- updated-dependencies: - dependency-name: poetry dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> * Update test * Add changelog entry --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Ed Morley <[email protected]>
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
pip 24.1+ rejects packages that use invalid versions in their metadata (such as Celery older than v5.2.1). We now annotate such failures with additional help text, mentioning the package needs to be upgraded, and link to the changelog entry which has additional advice: https://devcenter.heroku.com/changelog-items/3073 GUS-W-17415804.
Since `read` defines the `line variable as global by default, meaning `line` was visible outside these functions.
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.
Since I've decided to defer Python 3.8 sunset by a month given the upcoming holidays and imminent change moratorium. This will also allow for adding an equivalent warning to the Python CNB, so both can be sunset at the same time. Xref: https://devcenter.heroku.com/changelog-items/2768 https://devcenter.heroku.com/articles/python-support#supported-python-versions GUS-W-17422347.
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
After the recent Dev Center re-org, some of the articles URLs and/or heading anchor link names have changed. GUS-W-17428557.
To help gauge how often a uv lockfile exists. (Either from someone trying to use uv and the build failing, or when a third-party buildpack is used to export the uv lockfile to a requirements file etc). Towards #1616. GUS-W-17431743.
- 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.
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
* Bump the ruby-dependencies group with 3 updates Bumps the ruby-dependencies group with 3 updates: [logger](https://github.com/ruby/logger), [rubocop](https://github.com/rubocop/rubocop) and [rubocop-rspec](https://github.com/rubocop/rubocop-rspec). Updates `logger` from 1.6.2 to 1.6.4 - [Release notes](https://github.com/ruby/logger/releases) - [Commits](ruby/logger@v1.6.2...v1.6.4) Updates `rubocop` from 1.69.1 to 1.69.2 - [Release notes](https://github.com/rubocop/rubocop/releases) - [Changelog](https://github.com/rubocop/rubocop/blob/master/CHANGELOG.md) - [Commits](rubocop/rubocop@v1.69.1...v1.69.2) Updates `rubocop-rspec` from 3.2.0 to 3.3.0 - [Release notes](https://github.com/rubocop/rubocop-rspec/releases) - [Changelog](https://github.com/rubocop/rubocop-rspec/blob/master/CHANGELOG.md) - [Commits](rubocop/rubocop-rspec@v3.2.0...v3.3.0) --- updated-dependencies: - dependency-name: logger dependency-type: direct:development update-type: version-update:semver-patch dependency-group: ruby-dependencies - dependency-name: rubocop dependency-type: direct:development update-type: version-update:semver-patch dependency-group: ruby-dependencies - dependency-name: rubocop-rspec dependency-type: direct:development update-type: version-update:semver-minor dependency-group: ruby-dependencies ... Signed-off-by: dependabot[bot] <[email protected]> * Fix pipenv tests after new certifi release Since the new version number is wider, which caused the pip table rendering to change. --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Ed Morley <[email protected]>
The error messages shown when buildpack detection fails (or when detection passes, but no required package manager files are found later) include a file listing of the project to help with debugging. (e.g. to make misspellings or having forgotten to commit files more obvious.) Previously these file listings didn't include dotfiles, which meant not all project files would be shown. This is particularly relevant given that the the newly supported `.python-version` file is a dotfile. GUS-W-17524155.
This adds more Python project related file and directory names to the list recognised by buildpack detection. Such apps will still fail to build successfully (since they are missing a package manager file), but will now be shown a more helpful error message during compile, rather than the generic: "No default language could be detected for this app" The list is based on builds logs analysis of builds that filed to pass detection, plus builds that passed detection but didn't have a valid package manager file. (Possible since the build logs error message includes a file listing of the root directory of the app.) GUS-W-17530056.
Co-authored-by: heroku-linguist[bot] <136119646+heroku-linguist[bot]@users.noreply.github.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Fetch from upstream repo.