ehmatthes / heroku-buildpack-python Goto Github PK

This project forked from heroku/heroku-buildpack-python

A demonstration version of the official Heroku buildpack for Python apps, showing how Django deployment can be further simplified.

Home Page: https://ehmatthes.com/blog/simplified_heroku/

License: MIT License

Shell 42.69% Makefile 1.96% Dockerfile 1.26% Ruby 54.09%

heroku-buildpack-python's Introduction

Heroku Buildpack: Python

This is the official Heroku buildpack 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.

See it in Action

$ ls
my-application		requirements.txt	runtime.txt

$ git push heroku main
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 276 bytes | 276.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Python app detected
remote: -----> Installing python
remote: -----> Installing pip
remote: -----> Installing SQLite3
remote: -----> Installing requirements with pip
remote:        Collecting flask (from -r /tmp/build_c2c067ef79ff14c9bf1aed6796f9ed1f/requirements.txt (line 1))
remote:          Downloading ...
remote:        Installing collected packages: Werkzeug, click, MarkupSafe, Jinja2, itsdangerous, flask
remote:        Successfully installed Jinja2-2.10 MarkupSafe-1.1.0 Werkzeug-0.14.1 click-7.0 flask-1.0.2 itsdangerous-1.1.0
remote:
remote: -----> Discovering process types
remote:        Procfile declares types -> (none)
remote:

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.10.7

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.10.7 on all supported stacks
python-3.9.14 on all supported stacks
python-3.8.14 on Heroku-18 and Heroku-20 only
python-3.7.14 on Heroku-18 and Heroku-20 only

heroku-buildpack-python's People

Contributors

Stargazers

Watchers

Forkers

django-mariyan just-started

heroku-buildpack-python's Issues

Next steps

I'm trying this with a more complex project, and getting my head back around how the buildpack works. Some notes for next time:

All of my work so far is on the simplify_deploy branch.
- This has been merged to master, so the readme reflects this fork, and not the official Heroku buildpack.
Most of the work is done in bin/steps/autoconfigure.
- The autoconfigure script is called from bin/compile.
This is a really compelling project.

Define full set of config vars

Right now there's only one config var, AUTOCONFIGURE_ALL. That's been good enough to get started, but I need more in order to handle the range of approaches to autoconfiguration that people will need.

Define the full set of config vars, and then implement them.

Configure database automatically

Migrating and using the db should fail, because I'm only using SQLite locally, and Heroku uses Postgres. Automatically install libraries needed to use postgres, and configure settings to use this db when on heroku.

Successes and Failures

Have you tried to deploy a project using this buildpack? If so, what worked well? What didn't work?

Write reporting code?

Currently, I have no real idea how many times this deployment process has been used. I do not want to track individual users or projects. I would like a simple count of how many times this has been used.

Make a simple request to a server and log requests?
- The request carries no information.
- Document this clearly, so there are no surprises. Include in output that this counter was incremented.
- Offer a DISABLE_AUTOCONFIGURE_REPORTING env var that turns this feature off.

Set AUTOCONIGURE_ALL

It is set, but it's not available at beginning of script.

When are config variables read?

Merge current upstream changes

As of today (10/18/20), this fork is 86 commits behind the official heroku buildpack. Try merging the upstream changes, and see how much conflict there is.

I haven't done this before; my guess is one good approach if there are multiple conflicts is to bisect the upstream changes, and try merging ie 43 commits ago, and isolate pretty quickly specific commits that caused conflicts.

See: https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/merging-an-upstream-repository-into-your-fork

Automate initial migration?

Most projects, on initial deployment, will call migrate. If there's a way to tell that this is an initial deployment, does it make sense to call python manage.py migrate? This reduces the number of steps, and means you can just run heroku open right after pushing.

Beyond a proof of concept

The initial goal of this project was to provide a proof of concept that all initial deployment work could be done on Heroku's end, and require no local changes. To that end I have taken some shortcuts, such as setting ALLOWED_HOSTS = ['*'] (this has been addressed now).

As each of these is addressed in a more robust way, this moves closer to becoming a reliable real-world buildpack, not just a proof of concept. This issue is meant to keep track of issues that need to be addressed and questions that need to be answered in order to move beyond the proof of concept stage.

Include instructions for what to track with Git

Since deployment depends on using Git to manage the project, include specific instructions for what to track with Git for a successful deployment.

Configure ALLOWED_HOSTS

This is the current error, so address this next.

Set ALLOWED_HOSTS in settings.py to something that works on Heroku.

Merge current upstream changes, 101721

See #12, and my_docs/merging_upstream.md.

Minor cleanups

A single issue for small cleanups I notice, that don't each need a separate issue.

Indent reporting about static file configuration.

Needs a requirements.txt file or Pipfile

Current instructions say this assumes you're already using Git to track the project and have the Heroku CLI installed. But people also need to have a requirements.txt or Pipfile. Mention this in instructions, and how to do this.

Should also include instructions for how to use Git specifically, ie db.sqlite3 in .gitignore.

Create a simple demo repo for this

Make a fully-updated version of learning log, that runs with SQLite on local runserver.
Include instructions to download, make minimal configuration changes, and push to heroku.

Configure static files automatically.

My project is serving static files with DISABLE_COLLECTSTATIC=1. But that's probably because these are served from a CDN.

Unset DISABLE_COLLECTSTATIC, use whitenoise, troubleshoot.

Make `git push heroku master` not fail, then work through details

Right now, creates Procfile. collectsatic is disabled. Build doesn't error out, but app not up because gunicorn is not installed. Fix these kinds of issues before focusing on details like db and static files.

Will this work on DO?

See here, because DO app platform uses the heroku buildpack.

Don't require runtime.txt

This doesn't make the push fail, but currently this leads to Python 3.6.10 being installed!

Update so that default Python used is 3.8.3.

Pull current Python runtime?

Is there a way to use the most recent version of Python runtime that Heroku supports, without hard-coding it?

Document merge process

As long as this project is active, it's important to stay relatively up to date with upstream changes. To make this a little easier when I get out of the mindset of this project (and to help others contribute), document the process of merging from upstream.

First merge issue is here, and was straightforward.

Make python buildpack easier to use for beginners

Heroku is much easier for beginning Django developers to deploy to than a VPS such as Digital Ocean or Linode. But there's still a fair bit of configuration that has to be done between having a project that runs on your local machine and one that runs on Heroku.

This project aims to simplify the deployment process as much as possible, while doing things, as much as possible, in a standardized Heroku way. The process should be easy to override as people learn more about custom deployments.

Support Pipfiles

Handling projects that use a Pipfile instead of requirements.txt shouldn't be too difficult. It should be a matter of:

Detecting which kind of file is being used.
Writing to the appropriate file.
Writing in the correct format.

Write a simple testing script.

Write a script that builds an instance of the learning log project, deploys it, and opens the project.

Rename this project?

The project currently has the same name as the official Heroku Python buildpack. This project specifically builds Django projects, and focuses on auto-configuration. Perhaps a more specific name would be better?

django-auto-buildpack?
python-buildpack-auto?
- This leaves room to possibly add support for auto-configuring Flask apps as well, but that seems out of scope.