Since:
* We want the S3 bucket to be owned by a different AWS account and it's
not possible to transfer ownership of an existing bucket.
* In the future we want to rebuild some of the Python runtime archives
(for example to improve the sqlite3 handling, or to tweak the compile
flags used), and it will be easier to reason about the change if we
can guarantee only recent buildpack versions are using the assets
rather than several year old unmaintained forks.
The assets were synced from the old bucket using (minus the `--dryrun`):
```
aws s3 sync s3://lang-python s3://heroku-buildpack-python \
--dryrun \
--metadata-directive REPLACE \
--exclude "*" \
--include 'common/*' \
--include 'heroku-*/runtimes/*' \
--include 'heroku-*/libraries/vendor/gdal.tar.gz' \
--include 'heroku-*/libraries/vendor/geos.tar.gz' \
--include 'heroku-*/libraries/vendor/proj.tar.gz' \
--exclude 'common/pip-20.0.2-py2.py3-none-any.whl' \
--exclude '*/runtimes/*-opt.tar.gz' \
--exclude '*/runtimes/sqlite-free/*'
```
The files that were `--exclude`d are those that are no longer used,
or test assets that were not officially released.
The Cedar-14 assets were not migrated since it's EOL next month.
The old S3 bucket will be left untouched for the foreseeable future
(ie: we won't be deleting it), since builds using older versions of this
buildpack (either due to pinning to a tag or via a fork) will still be
using assets from it.
Closes @W-8060097@.
The tests use `test/shunit2` so the copy under `vendor/` is redundant.
I've added to the CHANGELOG since `vendor/` is added by the buildpack to
`PATH` (something long term we should stop doing), increasing the chance
an app was accidentally relying upon `shunit2` (albeit still unlikely).
Closes @W-8145517@.
Previously the buildpack's S3 bucket was defined in two places - once
in `VENDOR_URL` and again during the pip installation step. This
duplication was necessary since `VENDOR_URL` also contained the stack's
name, whereas the pip use-case used a non-stack-specific S3 key prefix.
In order to:
* reduce this duplication
* simplify this buildpack's S3 bucket migration (where we'll soon be
needing the vary the bucket name and wouldn't want to have to
duplicate that logic in multiple places)
* allow overriding of the URL for the pip use-case
...the `VENDOR_URL` variable has been replaced with `S3_BASE_URL` which
no longer contains the stack name.
The user-configurable override has similarly been renamed from
`BUILDPACK_VENDOR_URL` to `BUILDPACK_S3_BASE_URL`. Note: As before,
this override cannot be set via standard app variables (see #989).
The unused `USE_STAGING_BINARIES` environment variable has been
removed, since it's a leftover from the project to stand up a staging S3 bucket.
It's redundant given the `BUILDPACK_S3_BASE_URL` variable.
Closes @W-8142401@.
* Moves all manual build steps to make targets, to simplify
the commands run, and reduce chance for error.
* Removes the need to remember to rebuild the builder
image by building it automatically prior to launching.
* Adds a new make target for deploying multiple runtime
versions at once to speed up the common case.
* Reduces repetition/superfluous content in documentation.
* Removes unused `S3_REGION` from `dockerenv.default`
(the contents of S3 buckets inherit the region of the bucket).
* Documents build dependencies in `requirements.txt`.
Closes @W-8119717@.
[skip changelog]
* Switches from using Python 2 to Python 3 for `bob-builder`
* Adds `--no-install-recommends` to reduce unnecessary packages
* Removes unnecessary pinning of pip for Heroku-18 build
* Moves `DEBIAN_FRONTEND` to RUN level env var, given:
https://serverfault.com/a/797318
Refs @W-8119717@.
[skip changelog]
There were previously 6 virtually identical tests checking the handling of
a non-existent Python version being specified in `runtime.txt`.
Only one is necessary - removing the rest will improve CI run time.
Closes @W-8110383@.
[skip changelog]
Previously the test for Python 3.8 version warnings was named the same
as an earlier test for Python 3.7, meaning the earlier test definition
was overwritten and so never run.
The later test has now been renamed to the correct version, and the
test ordering adjusted for consistency with the rest of the file.
Closes @W-8110123@.
[skip changelog]
Since the `tool.pipenv` event is being emitted twice per pipenv build,
inflating its usage.
This whole file could do with a massive refactor (4 levels deep of
conditionals is never a good sign), but that can wait until a later PR.
In the future it would also be great to have testing of metrics events.
Closes @W-8094963@.
Currently an app's Python version can be set via a few different means:
- explicitly by the user (via `runtime.txt` or `Pipfile.lock`)
- implicitly via the sticky versions feature (for existing apps)
- implicitly via default version for new apps / those with empty cache
In order to determine the priority of features like automatic Python
patch version upgrades for sticky-versioned apps, it's useful to have
metrics for these.
There were previously no tests for either the sticky versions feature,
or changing the Python version by updating the `runtime.txt` file, so
I've added some now (given that I updated the conditional to add the
metrics, so useful to have coverage).
I've also removed the confusing overwrite of `DEFAULT_PYTHON_VERSION`
with the cached version, and kept them as two separate variables.
Closes @W-8099632@.
Closes @W-8099645@.
Previously the metric events describing the chosen Python version were
only emitted when that Python version was installed, and not when it
was being used from the build cache (the common case).
Now the version is emitted for all builds, improving visibility into
the distribution of Python usage, and helping determine the priority
of features like opt-in automatic Python patch updates.
Closes @W-8059668@.
The existing Python 3.4.10 archive actually contained Python 3.7.2,
since the version in the source URL was not updated when the file was
created in #813.
The build formula now uses the shared build script approach like all of
the other build scripts, which ensures the version can never get out of
sync (since it's extracted from the formula filename).
The build for Heroku-18 failed to compile `_ssl` properly (even though
the build exited zero) since Python 3.4.10 is old enough it doesn't work
well with libssl1.1. Installing `libssl1.0-dev` in the build image
locally resolved the issue - however we don't want to use that in the
future for newer Python, so I've not updated the `heroku-18.Dockerfile`.
In addition, with the rebuilt archives the tests now pass on Cedar-14,
so no longer need to be marked as failing.
Closes @W-7947035@.
The Hatchet run requires a valid Heroku login, the credentials for which
are set via Travis secure environment variables, which by design are not
revealed to PRs from forks.
The previous conditional wasn't working as intended - the Hatchet job
was still being triggered for forks from PRs.
The new conditional fixes this, and also means that forks could set
their own credentials via Travis environment variables if they wanted
a way to run the tests in CI on their own repo.
See:
https://docs.travis-ci.com/user/conditions-v1Fixes#1019.
Closes @W-7918482@.
[skip changelog]
Since they are now set via the Travis repository level secrets feature
instead. This both works around the Travis bug seen in #1045, and also
means its easier to set up Travis on forks, since otherwise the
`.travis.yml` secrets would overwrite the global secrets.
As part of this move the test account used has also been changed, and
will be documented here:
https://github.com/heroku/languages-team/blob/main/guides/create_test_users_for_ci.md#known-usernames
Closes @W-7949880@.
[skip changelog]
Since these variables refer to the latest version of PyPy, compared to
the similarly named `PYPY27` and `PYPY36` variables (ie same name except
without the underscore) which refer to the major/minor version only.
The similar names caused me to use the wrong one locally whilst working
on another PR, which was caught by tests but demonstrates why we should
rename them.
Closes @W-7935256@.
[skip changelog]
Since the unit tests instead use the utilities in this separate file:
https://github.com/heroku/heroku-buildpack-python/blob/419ef479969c4d5945f2c0620292229ef464f4c8/test/utils
A changelog entry has been added since whilst this file is for internal
testing only, the buildpack's `vendor/` directory is put on `PATH`, so
in theory it could have been called outside the buildpack (though this
seems extremely unlikely since the script isn't very useful externally).
Fixes#1027.
Closes @W-7918496@.
Since we don't use that tool (<https://pre-commit.com>), and there are
better alternatives should we want to expand coverage of these kind of
things.
Closes @W-7923935@.
[skip changelog]
It stopped being used as of #781.
```
$ rg ci-setup.sh --stats
0 matches
$ git-content-search ci-setup.sh
e7da63f update to newer hatchet integration
M .travis.yml
576def4 fix travis dependency blocker
M .travis.yml
$ git show e7da63f | rg ci-setup.sh -C 1
-before_install:
- - sudo bash etc/ci-setup.sh
+ - bundle exec hatchet ci:setup
```
Hatchet embeds its own setup script, which is called via the rake task:
https://github.com/heroku/hatchet/blob/v6.0.0/etc/ci_setup.rb
Closes @W-7923930@.
[skip changelog]
Previously if an app was using an older version of PyPy, the buildpack
would show a confusing "Could not find that version" message (even
though the version was found), when it really meant to warn about there
being a newer release available.
It looks like the version check messages were perhaps copied and pasted
from something else, but the message wording not updated at the time.
I've also added tests since there were none for this feature.
Fixes#1004.
Closes @W-7918745@.
So that any failures during `hatchet ci:setup` cause the build to fail
early, rather than try to proceed with running the Hatchet tests.
@W-7929878@
[skip changelog]
This will allow for one-way sync of GitHub issues in this repository
into our internal issues tracker, GUS. Issues are only synced when the
specified GitHub label is added.
In the future I may switch the chosen label to just be the standard
`t: bug` type labels, but for now I'm choosing a separate label so that
we have more control over what is synced.
See:
https://lwc-gus-bot.herokuapp.com/#getting-started
@W-7918433@
- Switches releases to always using H2 (`##`) rather than a mixture of
H1s (meaning multiple H1s in the same document) and H2s.
- Always refers to the versions as `vNNN` rather than sometimes without
the `v` prefix.
- Other formatting and typo fixes.
@W-7905079@
Updates pip from 20.0.2 to 20.1.1 for Python 2.7 and Python 3.5+:
https://pip.pypa.io/en/stable/news/#id40
The version used for Python 3.4 remains unchanged at 19.1.1, since it's
the last version of pip that supports it.
Pip has been updated to 20.1.1 rather than the recently released 20.2,
since the latter has a few regressions and even though these will be
fixed shortly in 20.2.1, we should let the changes soak for longer
before picking them up.
The `PIP_NO_PYTHON_VERSION_WARNING` environment variable has been set
(equivalent to passing `--no-python-version-warning`) to prevent the
Python 2.7 EOL warnings added in pip 20.1 from spamming the build log:
https://github.com/pypa/pip/blob/20.1.1/src/pip/_internal/cli/base_command.py#L139-L154
This was set via environment variable rather than CLI flag, since:
* otherwise we'd have to pass it to every pip invocation
* older pip (such as the 19.1.1 used by Python 3.4) doesn't support this
option and would error out due to an unknown CLI flag being passed,
unless we added conditional flags throughout.
The new pip wheel was uploaded to S3 using:
```
$ pip download --no-cache pip==20.1.1
Collecting pip==20.1.1
Downloading pip-20.1.1-py2.py3-none-any.whl (1.5 MB)
Saved ./pip-20.1.1-py2.py3-none-any.whl
Successfully downloaded pip
$ aws s3 sync . s3://lang-python/common/ --exclude "*" --include "*.whl" --acl public-read --dryrun
(dryrun) upload: ./pip-20.1.1-py2.py3-none-any.whl to s3://lang-python/common/pip-20.1.1-py2.py3-none-any.whl
$ aws s3 sync . s3://lang-python/common/ --exclude "*" --include "*.whl" --acl public-read
upload: ./pip-20.1.1-py2.py3-none-any.whl to s3://lang-python/common/pip-20.1.1-py2.py3-none-any.whl
```
Fixes#1005.
@W-7659489@
Upgrades setuptools from 39.0.1 to:
- 44.1.1 for Python 2.7 (since it's the last supported version)
- 43.0.0 for Python 3.4 (since it's the last supported version)
- 47.1.1 for Python 3.5+ (since we can't use 47.2.0+ until #1006 fixed)
https://setuptools.readthedocs.io/en/latest/history.html#v47-1-1Fixes#949.
Closes#973.
They are now displayed in the build output (instead of being sent to
`/dev/null`) and fail the build early instead of failing later in
`bin/steps/pip-install`.
Fixes#1002.
Since the version check is redundant given we control/choose the version.
The pip cache is redundant since we instead cache site-packages. The pip
cache also ends up in `/app` so isn't included in the build cache anyway.
`get-pip.py` is no longer used, since:
- It uses `--force-reinstall`, which is unnecessary here and slows down
repeat builds (given we call pip install every time now). Trying to
work around this by using `get-pip.py` only for the initial install,
and real pip for subsequent updates would mean we lose protection
against cached broken installs, plus significantly increase the
version combinations test matrix.
- It means downloading pip twice (once embedded in `get-pip.py`, and
again during the install, since `get-pip.py` can't install the
embedded version directly).
- We would still have to manage several versions of `get-pip.py`, to
support older Pythons (once we upgrade to newer pip).
We don't use `ensurepip` since:
- not all of the previously generated Python runtimes on S3 include it.
- we would still have to upgrade pip/setuptools afterwards.
- the versions of pip/setuptools bundled with ensurepip differ greatly
depending on Python version, and we could easily start using a CLI
flag for the first pip install before upgrade that isn't supported on
all versions, without even knowing it (unless we test against hundreds
of Python archives).
Instead we install pip using itself in wheel form. See:
https://github.com/pypa/pip/issues/2351#issuecomment-69994524
The new pip wheel assets on S3 were generated using:
```
$ pip download --no-cache pip==19.1.1
Collecting pip==19.1.1
Downloading pip-19.1.1-py2.py3-none-any.whl (1.4 MB)
Saved ./pip-19.1.1-py2.py3-none-any.whl
Successfully downloaded pip
$ pip download --no-cache pip==20.0.2
Collecting pip==20.0.2
Downloading pip-20.0.2-py2.py3-none-any.whl (1.4 MB)
Saved ./pip-20.0.2-py2.py3-none-any.whl
Successfully downloaded pip
$ aws s3 sync . s3://lang-python/common/ --exclude "*" --include "*.whl" --acl public-read --dryrun
(dryrun) upload: ./pip-19.1.1-py2.py3-none-any.whl to s3://lang-python/common/pip-19.1.1-py2.py3-none-any.whl
(dryrun) upload: ./pip-20.0.2-py2.py3-none-any.whl to s3://lang-python/common/pip-20.0.2-py2.py3-none-any.whl
$ aws s3 sync . s3://lang-python/common/ --exclude "*" --include "*.whl" --acl public-read
upload: ./pip-19.1.1-py2.py3-none-any.whl to s3://lang-python/common/pip-19.1.1-py2.py3-none-any.whl
upload: ./pip-20.0.2-py2.py3-none-any.whl to s3://lang-python/common/pip-20.0.2-py2.py3-none-any.whl
```
Previously the pip/setuptools/wheel install step was skipped so long
as Python hadn't just been clean installed (ie so long as not a new app,
emptied cache, Python upgrade, stack change) and pip was the expected
version.
This meant that setuptool/wheel could be the wrong version (or even just
not installed at all), and this would not be corrected.
Now, we now use pip itself to determine whether the installed packages
are up to date, since parsing pip's output is fragile (eg #1003) and
would be tedious given there would be three packages to check.
Unfortunately `get-pip.py` uses `--force-reinstall` which means
performing this step every time is not the no-op it would otherwise be,
but this will be resolved by switching away from `get-pip.py` in the
next commit.
Fixes#1000.
Fixes#1003.
Closes#999.
Since `get-pip.py` / pip will automatically detect and remove old
pip/setuptools versions if needed, so removing them manually is both not
necessary and slows down the build in the case where the pip version
changed, but setuptools remained the same.
Before:
- if `wheel` was not already installed, then `get-pip.py` would
automatically install the latest version on PyPI, which is `0.34.2`
(or `0.33.6` for Python 3.4).
- if `wheel` was already installed, then it was left unchanged
regardless of the version installed.
Now:
- if `wheel` is not already installed, then the same versions will be
installed as before, except these versions are pinned and will now not
change unexpectedly after future `wheel` releases.
- if `wheel` is already installed, then it's upgraded/downgraded to the
target version as needed.
Partly addresses #1000, though this change only helps builds where the
pip/setuptools/wheel install flow is triggered (currently only new apps
or ones where Python was purged or pip was not the correct version).
Since the wheel version is now known, it's output to the build log to
ease debugging and for parity with pip/setuptools.
The rest of #1000 will be fixed in later commits.
Since:
* we'll be updating setuptools soon, and newer setuptools has dropped
support for Python versions this buildpack needs to support. As such
if we continued to vendor setuptools, we would need to vendor at
least three different versions.
* we want to try and update setuptools more frequently than we have
in the past, which will mean more repo bloat from binary churn.
* we're still pinning to a specific version, meaning vendoring doesn't
have determinism benefits.
* setuptools is only fetched from PyPI for new installs (or where
versions have changed), so this doesn't increase build time, load on
PyPI, or reliance on PyPI in the common case.
* setuptools is already being inadvertently installed from PyPI prior to
being installed from the vendored copy (see #1001), so we're in effect
already using/depending on PyPI here.
* switching to storing setuptools on S3 wouldn't help reliability as
much as it would appear at first glance, since the later `pip install`
of customer dependencies will fail if PyPI is down anyway.
Since:
* "explicit is better than implicit"
* we'll soon be upgrading setuptools, and debugging breakage caused by
upgrades will be easier if versions are visible in the build log
Since:
* "explicit is better than implicit"
* we'll soon be upgrading pip, and debugging breakage caused by upgrades
will be easier if versions are visible in the build log
Closes#939.
The following env vars are no longer exposed to subprocesses run by the
buildpack (such as the `bin/pre_compile` and `bin/post_compile` hooks):
* `BPLOG_PREFIX`
* `CACHED_PYTHON_STACK`
* `DEFAULT_PYTHON_STACK`
* `DEFAULT_PYTHON_VERSION`
* `LATEST_27`
* `LATEST_34`
* `LATEST_35`
* `LATEST_36`
* `LATEST_37`
* `LATEST_38`
* `PIP_UPDATE`
* `PY27`
* `PY34`
* `PY35`
* `PY36`
* `PY37`
* `PYPY_27`
* `PYPY_36`
* `RECOMMENDED_PYTHON_VERSION`
* `WARNINGS_LOG`
There were previously no tests at all for the pre/post-compile hooks,
so I've added some now.
Fixes#1010.
This change (along with #1021, which skips an unnecessary docker build)
reduces the wall clock time from ~22 minutes to ~6 minutes. Even with
the additional overhead from increased parallelism, the combined job
duration (~50 minutes) has not increased due to the other time savings.
Changes:
- for the unit tests, each stack is now tested in its own job and so
tested in parallel
- the use of Travis stages has been removed, since by design it blocks
later tasks on earlier stages having completed - reducing parallelism
unnecessarily for this use case
- all jobs except for the Hatchet job now use Travis' `minimal` image,
and no longer install redundant Ruby + bundler
- the `sudo: {required,false}` references have been removed, since
Travis no longer supports its non-sudo container infrastructure so
ignores that option
Fixes#1018.
[skip changelog]
Previously `make test` ran all unit test suites against all stacks, which
would take up to an hour locally. This could be sped up by using one of
the stack-specific targets (such as `make test-heroku-18`), however
there was still no way to only run one of the test suites.
Now `make test` can be controlled more precisely using optional `STACK`
and `TEST_CMD` arguments, eg:
`make test STACK=heroku-16 TEST_CMD=test/versions`
Travis has now been made to use this feature, which unblocks future
Travis speedups (such as splitting the jobs up further in #1018) and
means on Travis the correct Docker image is now used (see #958).
The `tests.sh` script has been removed since it's unused after #839 and
redundant given the make targets.
Fixes#958.
Fixes#1020.
To prevent external environment variables from leaking into the tests,
which otherwise causes problems trying to write tests for #1011.
Several tests which were relying on this leak had to be fixed, so that
the env vars they were using are set using `ENV_DIR`, as happens in
production.
Fixes#1014.
Fixes#1015.
Adds support for:
* CPython 2.7.18, 3.5.9, 3.7.7 and 3.8.3
* PyPy 2.7 and 3.6, version 7.3.1
The binaries will need generating and uploading before CI will pass.
Note: Whilst the build script for CPython 3.8.3 did already exist in the
repository, it appears to have been accidentally created in #920, which
predated the existence of that version of Python - so the binaries do
not exist on S3.
The Heroku-18 Docker image tag has also been unpinned, since the new
libssl version is now available at runtime in all environments, so we
don't need to force building against the older version of the headers.
Fixes W-7582174.
Previously when a PR title was edited, the "check for changelog" script would not fire. This means if someone edited it to add a "[changelog skip]" that the check would still show to be failing. This PR adds additional triggers for the check so that when the PR is edited, the check will re-run.
* Update travis conditional for hatchet to check for HEROKU_API_ env vars
[changelog skip]
* remove check to skip hatchet in travis in favor of better travis config
The compile-time cryptography step that used to use the libffi archives
on S3 was removed in 2018:
https://github.com/heroku/heroku-buildpack-python/commit/c373e80c1285260e5adcbc855f54bbeb6999005c
...since the `cryptography` Python package now ships wheels.
The script is also incorrect, since similar to #964 it only skips builds
for Heroku-16, whereas all stacks since Cedar-14 include libffi-dev in
the build image, so don't need it built/uploaded for later vendoring.
Refs W-7485877.
The `libmemcached` package is available in the base stack image for all
stacks newer than `cedar-14`, so at buildpack compile time the vendor
step is skipped for those stacks:
https://github.com/heroku/heroku-buildpack-python/blob/106f2997fa124852a2a35ee8bfa604ad20c47988/bin/steps/pylibmc#L12-L15
As such, it is not necessary to run the libmemcached bob-builder formula
on newer stacks. The conditional has been updated so it correctly handles
heroku-18 and also the upcoming heroku-20.
An exit code of 1 has been used, otherwise `bob upload` will build and
then upload a zero byte archive to S3, which will go unused.
(This is in comparison to bob formulas that are nested, where an exit
code of 0 is actually desirable, since it allows skipping steps.)
Refs W-7485877.
Co-authored-by: Joe Kutner <jpkutner@gmail.com>
These aren't referenced anywhere in the repository, and contain older
versions of the dependencies than are declared in `requirements.txt`
(which itself is used).
Co-authored-by: Joe Kutner <jpkutner@gmail.com>
* Update travis config to only setup hatchet when running hatchet [changelog skip]
Fix a bug in the hatchet tests, and allow previous builds to finish before running the next test
* Add logging when skipping hatchet tests
Only skip hatchet tests on a forked PR
* Build on Travis only for master branch
* Upgrade from trusty to bionic on Travis
* Add support for Python 3.8 latest version
If the pip lock file only specifies `3.8` and no bug fix version, it should use Python LATEST_38.
* Update CHANGELOG.md
* Update changelog
Co-authored-by: Johannes Hoppe <info@johanneshoppe.com>
Co-authored-by: Casey <caseylfaist@gmail.com>
* Add a Hatchet test for python 3.8.2
* update changelog
* Update test to match build output
* Fix formatting and a syntax error in tests
* Fix syntax error in hatchet spec
* Don't clear the cache on first app deploy
* Add output for debugging cache behavior
* Debug output of changes, clean up whitespace
* Update hatchet to use latest getting started guide
* Clean up caching output logs
This output was confusing and unhelptul to most users
* Changelog
* Test if we need these lines
* dang fi
* Remove unnecessary code
* Remove confusing output of change
* Update log output
* Update test to match new expected log output
* Update changelog
This addresses an issue raised by @CaseyFeist during code review:
Updating pip for pipenv users or requiring them to update without a
heads up won't be a good experience (our version is old enough that
they'll need to uninstall and reinstall pipenv locally to successfully
update). If you can refactor this to stay pinned to current version for
pipenv users only, I should be able to accept this (and the related
project updates).
https://github.com/heroku/heroku-buildpack-python/pull/833#issuecomment-537758441
The pip-diff and pip-grep tools from the vendorized `pip-pop` package
import internal modules from pip. In pip >= 10, internal modules were
moved under `pip._internal`, breaking the imports. Use `try...except
ImportError` to handle both import paths.
Also, the interface of the `PackageFinder` class from one of these
modules changed. Provide a wrapper function to allow creating objects of
this type using the old interface.
This reverts commit c410fd36a6.
This is a temporary revert in order to release new python binaries first
and then roll this change out in a separate release. This keeps releases
smaller and better organized in case we need to roll back.
The goal of this PR is to add a github action that checks for the presence of a changelog entry.
It is better to add entries as a PR is merged instead of having to remember what was merged and generate a changelog at release time.
By automating this check, it's one less thing the maintainer has to remember, and it's one less thing a change might be blocked on i.e. "Looks good, but please add a changelog entry".
Let me know if you have any questions and Happy Friday!
The pip-diff tool from vendor/pip-pop is used to determine stale
requirements. When pip-diff encounters an unexpected failure, a count is
logged using mcount from heroku/buildpack-stdlib.
Due to a typo, mount(8) was invoked instead of mcount, with an invalid
argument.
* new recipe for new runtime
* add new runtime formula
* add test updates for new runtime release
* wrangle tests into submission
* update tests to use default_pythons
* delete commented code
Due to how the version checks work - via sorting, not actual comparison - this previously resulted in _always_ installing sqlite3, even though it was already bundled for lower versions of python. The second version check also encompasses 3.7.0+, so there is no need to respecify the check.
It's occasionally useful to see at a glance when releases were pushed to understand what release might have caused a customer's issues. This back-fills dates for the last few months of releases and sets a precedent that can be followed in the future.
With inspiration from @KevinBrolly, this patch uses the stack image
SQLite3 package but also still providing the dev headers and binary that
users may still be using today. The benefit is that we won't need to
rebuild all the python binaries for this to take affect. We can just
stop shipping SQLite3 from future binaries. In addition, we don't need
to worry about what version and when to update SQLite3 and maintaining
the packages ourselves.
This also includes updates to Python 2.7.15 and Python 3.6.6 so they can
rebuilt with the stack image dev headers instead of building our own
vendored SQLite3.
- Add stage to Travis CI config and update tests.sh script to recognize
it
- Update tests to assert there is no Python 2 on Heroku-18
- Update nltk fixture to use Python 3.6 so we can test it on all stacks
Closes gh-730
Python 3.7.0 is supported but not preferred given how new it is. As a
result, we don't want it to be the default, but we also don't want users
to be confused when upgrading to it.
Closes gh-728
* Since pipenv is being pinned now, output pinned version in steps
Signed-off-by: Yury V. Zaytsev <yury.zaytsev@moneymeets.com>
* Update README.md example output to match new reality
Signed-off-by: Yury V. Zaytsev <yury.zaytsev@moneymeets.com>
* Update pipenv
Set GDAL and GEOS library locaiton explicitly in environment
variables:
* GDAL_LIBRARY_PATH "/app/.heroku/vendor/lib/libgdal.so"
* GEOS_LIBRARY_PATH "/app/.heroku/vendor/lib/libgeos_c.so"
Django has to settings with the same name. The setup now works as
described here:
https://devcenter.heroku.com/articles/postgis#geodjango-setup
* only do this on heroku-16
* history
Signed-off-by: Kenneth Reitz <me@kennethreitz.org>
* code comment
Signed-off-by: Kenneth Reitz <me@kennethreitz.org>
Found by diffing the published buildpack archives and looking at the
git log to see what changed. It looks like the v108 entry was
accidentally added in #405, when the release being published there
was actually v107. The setuptools update mentioned there never
happened, since the `SETUPTOOLS_VERSION` variable was found to be
unused and instead removed.
Previously the contents of the file being searched was not output,
making it hard to know how to fix a test so that it would pass.
Before:
```
$ make test-heroku-16
...
testCffi
ASSERT:Expected </tmp/shunit.ayVGAO/tmp/output.6gMs/stdout> to contain <ZZZZZZZ>
testPylibmc
```
After:
```
$ make test-heroku-16
...
testCffi
ASSERT:Expected </tmp/shunit.FXWeuI/tmp/output.7Vfx/stdout> to contain <ZZZZZZZ>
! Warning: Your application is missing a Procfile. This file tells Heroku how to run your application.
! Learn more: https://devcenter.heroku.com/articles/procfile
-----> Installing python-3.6.2
-----> Installing pip
-----> Installing requirements with pip
Collecting cffi (from -r /tmp/testBoLG0/requirements.txt (line 1))
Downloading cffi-1.10.0-cp36-cp36m-manylinux1_x86_64.whl (406kB)
Collecting pycparser (from cffi->-r /tmp/testBoLG0/requirements.txt (line 1))
Downloading pycparser-2.18.tar.gz (245kB)
Installing collected packages: pycparser, cffi
Running setup.py install for pycparser: started
Running setup.py install for pycparser: finished with status 'done'
Successfully installed cffi-1.10.0 pycparser-2.18
testPylibmc
```
* NLTK support: Update test to use multiple corpora
So that the incorrect handling of multiple IDs seen in #444 would
have been caught.
Also switches to some of the smaller corpora, to reduce time spent
downloading during tests (see sizes on http://www.nltk.org/nltk_data/).
* NLTK support: Fix passing of multiple corpora identifiers
As part of fixing the shellcheck warnigns in #438, double quotes had
been placed around `$nltk_packages` passed to the `nltk.downloader`,
which causes multiple identifiers to be treated as though it were just
one identifier that contains spaces.
The docs for the shellcheck warning in question recommend using arrays
if the intended behaviour really is to split on spaces:
https://github.com/koalaman/shellcheck/wiki/SC2086#exceptions
As such, `readarray` has been used, which is present in bash >=4.
The `[*]` array form is used in the log message, to prevent shellcheck
warning SC2145, whereas `[@]` is used when passed to `nltk.downloader`
to ensure the array elements are unpacked as required.
Note: Both before and after this fix, using anything but unix line
endings in `nltk.txt` will also cause breakage.
Reduces the impact on Travis runtime caused by #438, by:
* Making the shellcheck job run on the container infra (`sudo: false`)
which has faster boot times.
* Running the heroku-16 and cedar-14 stack tests in parallel, since
previously they were separate stages (which are run in series by
design).
Reduces Travis end-to-end time from ~10 minutes to ~6 minutes.
* Test that the cache is invalidated when the stack changes
* Improve UX when clearing cache due to the stack changing
Now outputs a message informing that the cache was cleared, and
clears the cache first to avoid a redundant message about removing
an old Python version.
This copies the official Docker Python images approach of stripping
the Python test suite after building from source.
For Python 3.6.2 this reduces the output from 184MB to 121MB and
removes the following directories:
```
.heroku/python/lib/python3.6/tkinter/test
.heroku/python/lib/python3.6/ctypes/test
.heroku/python/lib/python3.6/unittest/test
.heroku/python/lib/python3.6/distutils/tests
.heroku/python/lib/python3.6/sqlite3/test
.heroku/python/lib/python3.6/lib2to3/tests
.heroku/python/lib/python3.6/test
```
For Python 2.7.13 this reduces the output from 127MB to 91MB and
removes the following directories:
```
.heroku/python/lib/python2.7/ctypes/test
.heroku/python/lib/python2.7/unittest/test
.heroku/python/lib/python2.7/distutils/tests
.heroku/python/lib/python2.7/bsddb/test
.heroku/python/lib/python2.7/lib-tk/test
.heroku/python/lib/python2.7/sqlite3/test
.heroku/python/lib/python2.7/lib2to3/tests
.heroku/python/lib/python2.7/json/tests
.heroku/python/lib/python2.7/email/test
.heroku/python/lib/python2.7/test
```
Fixes#424.
The pip-uninstall step stopped working when it was moved to after
the pip-install step in f27a84e.
This regression was temporarily fixed by part of #397, however that
PR was reverted in #404.
Adds a test to hopefully catch any future regressions :-)
Fixes#393.
* Revert "Fix pyyaml (#402)"
This reverts commit ff94908505.
* Revert "Don't install packages that could mess packaging up (#397)"
This reverts commit 5496c02f9f.
* Revert "use pkg_resources to check for distributions (#395)"
This reverts commit 9b185f99d5.
* use sp-grep for django detection
* sp-grep
* fix setuptools script
* Updates bob-builder to a version that clears out the previous
build directory, which prevents the stale files seen in #379.
* Adds a `buildenv-heroku-16` Make command to simplify the
building and use of the Heroku-16 binary build environment.
* Sets `S3_BUCKET` and `S3_PREFIX` in the Docker image, to save
having to do so manually each time.
* Removes the duplication of the bob-builder dependency between
`Dockerfile` and `requirements.txt`.
* Disables the pip version check during Docker build, to avoid the
noisy stderr warning about Ubuntu 16.04 pip being older (v8.1.1).
* Adds a `.dockerignore` to speed up the Docker build, by reducing
the build context transferred to the daemon from 60MB to 2MB.
* Applies some Dockerfile best practices like disabling/removing
cached files (since layer invalidation makes caching pointless).
In cases where there is no stderr there was previously no output,
which made it hard to find the cause. The assertion messages have
also been adjusted to remove the repetition (shunit2 already outputs
expected vs actual itself).
Before:
```
testPipenv
ASSERT:Expected captured exit code to be 0; was <2> expected:<0> but was:<2>
testPipenvVersion
```
After:
```
testPipenv
ASSERT:Captured exit code - expected:<0> but was:<2>
! Warning: Your application is missing a Procfile. This file tells Heroku how to run your application.
! Learn more: https://devcenter.heroku.com/articles/procfile
-----> Installing python-2.7.13
-----> Installing pip
-----> Generating 'requirements.txt' with pipenv
testPipenvVersion
```
Fixes#389.
So that any changes made to `.heroku/` within pre_compile (such as
installing additional libraries required for the later pip install) are
not clobbered by the cache being copied over afterwards.
Fixes#320.
* update python.gunicorn.sh to WEB_CONCURRENCY.sh
* don't remove WEB_CONCURRENCY for prefixed 0s
* split gunicorn functionality into its own file
* cleanup comments
* fix var ordering
* add retry to curl
* use proper url for buildpack stdlib
The Node buildpack now exports a leading zero in its numbers. This lets us detect that it (or another buildpack) set the value, and overwrite it accordingly.
Fixes the issue where adding the node buildpack to a Python app would cause only one gunicorn worker to be spawned for a 1X dyno, and not two.
We also need to again produce leading zeroes in the value, so that e.g. the PHP buildpack can do the same on boot.
* drop duplicate mkdir for .heroku
* simplify linking and moving of python and source
* steps/python needs its own symlink setup
* fix symlink destinations for vendor and venv
* always symlink python
Since if someone previously had `GDAL` in their requirements file, they
would already have the gdalserver binary present from `bin/steps/gdal`
but be missing the proj and geos vendor files. By checking for `proj`
instead, we ensure that the vendoring isn't incorrectly skipped in this
case.
For both the cedar and cedar-14 stacks, the libffi directory is named
`libffi-3.1` not `libffi-3.1.1`, so the existing library wouldn't be
detected, causing it to be re-downloaded during every compile.
This means pip-pop will use the buildpack-installed pip 8, which doesn't
fail when encountering requirements files that use the new hash syntax.
Fixes#302.
The extraneous `format` call is harmless in itself, but it's possible for `requirement.req` to be `None` here, which results in `AttributeError: 'NoneType' object has no attribute 'project_name'`.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.
0. Additional Definitions.
As used herein, “this License” refers to version 3 of the GNU Lesser General Public License, and the “GNU GPL” refers to version 3 of the GNU General Public License.
“The Library” refers to a covered work governed by this License, other than an Application or a Combined Work as defined below.
An “Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.
A “Combined Work” is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the “Linked Version”.
The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.
The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.
1. Exception to Section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.
2. Conveying Modified Versions.
If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:
a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or
b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy.
3. Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:
a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license document.
4. Combined Works.
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:
a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.
b) Accompany the Combined Work with a copy of the GNU GPL and this license document.
c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)
5. Combined Libraries.
You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following:
a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License.
b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
6. Revised Versions of the GNU Lesser General Public License.
The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation.
If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy's public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.
pip-pop license
---------------
The MIT License (MIT)
Copyright (c) 2014 Kenneth Reitz.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
This is the official [Heroku buildpack](https://devcenter.heroku.com/articles/buildpacks) for Python apps.
Recommended web frameworks include **Django** and **Flask**, among others. The recommended webserver is **Gunicorn**. There are no restrictions around what software can be used (as long as it's pip-installable). Web processes must bind to `$PORT`, and only the HTTP protocol is permitted for incoming connections.
Python packages with C dependencies that are not [available on the stack image](https://devcenter.heroku.com/articles/stack-packages) are generally not supported, unless `manylinux` wheels are provided by the package maintainers (common). For recommended solutions, check out [this article](https://devcenter.heroku.com/articles/python-c-deps) for more information.
A `requirements.txt` must be present at the root of your application's repository to deploy.
To specify your python version, you also need a `runtime.txt` file - unless you are using the default Python runtime version.
Current default Python Runtime: Python 3.6.12
Alternatively, you can provide a `setup.py` file, or a `Pipfile`.
Using `pipenv` will generate `runtime.txt` at build time if one of the field `python_version` or `python_full_version` is specified in the `requires` section of your `Pipfile`.
Specify a Buildpack Version
---------------------------
You can specify the latest production release of this buildpack for upcoming builds of an existing application:
$ heroku buildpacks:set heroku/python
Specify a Python Runtime
------------------------
Supported runtime options include:
-`python-3.9.0`
-`python-3.8.6`
-`python-3.7.9`
-`python-3.6.12`
-`python-2.7.18`
## Tests
The buildpack tests use [Docker](https://www.docker.com/) to simulate
This is the official [Heroku buildpack](https://devcenter.heroku.com/articles/buildpacks) for Python apps, powered by [pip](https://pip.pypa.io/) and other excellent software.
Recommended web frameworks include **Django** and **Flask**. The recommended webserver is **Gunicorn**. There are no restrictions around what software can be used (as long as it's pip-installable). Web processes must bind to `$PORT`, and only the HTTP protocol is permitted for incoming connections.
Some Python packages with obscure C dependencies (e.g. scipy) are [not compatible](https://devcenter.heroku.com/articles/python-c-deps).
See it in Action
----------------
Deploying a Python application couldn't be easier:
A `requirements.txt` file must be present at the root of your application's repository.
You can also specify the latest production release of this buildpack for upcoming builds of an existing application:
$ heroku buildpacks:set heroku/python
Specify a Python Runtime
------------------------
Specific versions of the Python runtime can be specified with a `runtime.txt` file:
$ cat runtime.txt
python-3.5.1
Runtime options include:
-`python-2.7.11`
-`python-3.5.1`
-`pypy-4.0.1` (unsupported, experimental)
Other [unsupported runtimes](https://github.com/heroku/heroku-buildpack-python/tree/master/builds/runtimes) are available as well. Use at your own risk.
sed -e 's/\.\.\.\+/.../g' | sed -e '/already satisfied/Id' | sed -e '/Overwriting/Id' | sed -e '/python executable/Id' | sed -e '/no previously-included files/Id'
sed -e 's/\.\.\.\+/.../g' | sed -e '/already satisfied/Id' | sed -e '/No files were found to uninstall/Id' | sed -e '/Overwriting/Id' | sed -e '/python executable/Id' | sed -e '/no previously-included files/Id'
curl -L "${dep_url}" | tar jx -C "${OUT_PREFIX}" --strip-components 1 # extract to $OUT_PREFIX, drop the first directory level, which is the archive name
curl -fL "${dep_url}" | tar jx -C "${OUT_PREFIX}" --strip-components 1 # extract to $OUT_PREFIX, drop the first directory level, which is the archive name
curl -L "${dep_url}" | tar jx -C "${OUT_PREFIX}" --strip-components 1 # extract to $OUT_PREFIX, drop the first directory level, which is the archive name
curl -fL "${dep_url}" | tar jx -C "${OUT_PREFIX}" --strip-components 1 # extract to $OUT_PREFIX, drop the first directory level, which is the archive name
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ed Morley
kennethreitz