Does not seem to work on Heroku-16

[jbyrum]

We have two reports of this buildpack not working with Heroku-16, the next version of Heroku's stack based on Ubuntu 16.04:

https://devcenter.heroku.com/articles/heroku-16-stack

[filwaitman]

I was facing the issue as well on heroku-16.

I'm using it together with heroku/python buildpack.
Deploy was occurring with no warnings/errors but when I was trying to run a manage.py <whatever> inside the machine I was getting a huge stacktrace with final line:

OSError: libjasper.so.1: cannot open shared object file: No such file or directory

Rolling back to cedar-14 solved my issue, so I really think it's somewhat an incompatibility with heroku-16 new infra.

[giantryansaul]

Same issue for me. I am not an expert in GDAL or GIS libraries, in fact I'm fairly new to these areas, but I dove a little into this today and tried to reproduce the problem that I'm getting on the stack-trace directly on the server:

>>> CDLL('/app/.heroku/vendor/lib/libgdal.so')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/app/.heroku/python/lib/python3.5/ctypes/__init__.py", line 347, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: libjasper.so.1: cannot open shared object file: No such file or directory

I don't see libjasper anywhere in the geo libraries, so maybe this is what is missing?

[pvchaumier]

Similar issue for me. The stack is Heroku-16, Django 1.10, Python 3.5.2
The push works (and when print the django.contrib.gis.gdal.HAS_GDAL in the manage.py file, it is True) but the server won't start. It returns a Cannot import GDALRaster error.

I tried changing to cedar-14 but it would not solve it.
When I ssh into the machine, it seems gdal is not installed dpkg -l | grep gdal returns nothing. When I launch python and try import gdal it returns ImportError: libjasper.so.1: cannot open shared object file: No such file or directory
I also tried downgrading to Django 1.9 but in this case it is my app that does not work anymore.

Do you have any idea what could be wrong ?

[atiberghien]

It was fixed here by @dschep

Works for me
Cheers

[zachmccormick]

@dschep Can you make a branch without the changes to the readme and make a PR to this repo? I feel like a decent number of people use this repo as a buildpack and it would help a LOT of people to fix it :-)

[dschep]

Can do. I'll make a PR this evening.

[dschep]

Well, before I do that, would @cyberdelia have any interest in merging such a PR? They haven't responded to this issue.

[cyberdelia]

@dschep There is no guarantee this path is stable across two stack version, it would be better to vendor it this buildpack. I'm also unsure if adding the full file path will not break non-python libraries.

[zachmccormick]

I know that the copying of the libjasper file works across both stacks - I just submitted a PR to the official Python buildpack to that effect.

[zachmccormick]

Ah and I had no issues doing something like this in my settings.py for Django specifically:

GDAL_LIBRARY_PATH = '/app/.heroku/vendor/lib/libgdal.so'  # or os.getenv('...') and overriding it in Heroku app configuration

This could remove the need for changing the default GDAL_LIBRARY_PATH in the buildpack

[simonfromla]

How exactly do we use the fix by @dschep?

I've tried heroku buildpacks:set https://github.com/dschep/heroku-geo-buildpack.git (as written in the readme), heroku buildpacks:set https://github.com/TrailStash/heroku-geo-buildpack.git, as well as
heroku buildpacks:set https://github.com/TrailStash/heroku-geo-buildpack.git#5ae45e57353aab6a9fb2f0443e9ea0974d8b29ba for good measure, but neither seem to solve the libjasper issue.

Using the buildpacks will throw OSError: libjasper.so.1: cannot open shared object file: No such file or directory.

heroku-16, django 1.11.8

Relevant settings:

import dj_database_url
from os import environ

DATABASES['default'] =  dj_database_url.config()
DATABASES['default']['ENGINE'] = 'django.contrib.gis.db.backends.postgis'

GEOS_LIBRARY_PATH = "{}/libgeos_c.so".format(environ.get('GEOS_LIBRARY_PATH'))
GDAL_LIBRARY_PATH = "{}/libgdal.so".format(environ.get('GDAL_LIBRARY_PATH'))
PROJ4_LIBRARY_PATH = "{}/libproj.so".format(environ.get('PROJ4_LIBRARY_PATH'))

[dschep]

Not sure. I'm not using the project I initially built this for and i'm having trouble with the current project. I've got Django running, but fails when trying to save a geometry in django admin with an OGR failure error (seems to have trouble converting from one srid to another afaict). I'm about to just give up on heroku and just use a server, this is just too much of a hassle. The config I use that kinda works is:

if os.getenv('DYNO'):
    GDAL_LIBRARY_PATH = os.path.expandvars(os.getenv('GDAL_LIBRARY_PATH'))
    GEOS_LIBRARY_PATH = os.path.expandvars(os.getenv('GEOS_LIBRARY_PATH'))

Hmm looking at what you tried i'll give it one last shot and update PROJ4's path too. (this is using master of TrailStash/heroku-geo-buildpack which sets the vars with the shared object filename in the path.)

Edit: nevermind about proj4 path. That's nota ctually a setting in django: https://github.com/django/django/search?utf8=%E2%9C%93&q=PROJ4_LIBRARY_PATH&type=

[jodal]

Since heroku/heroku-buildpack-python@f767a73 landed in November, we've successfully been using heroku-16 and the plain heroku/python buildpack together with PostGIS. See https://devcenter.heroku.com/articles/postgis#geodjango-setup for what settings to define in your Django project.

[simonfromla]

per @jodal's comment, I tried it out using only the original heroku/python buildpack, and settings as defined only this page here: https://devcenter.heroku.com/articles/postgis#geodjango-setup.

And interestingly, it'll build up to the same point and throw the same error of OSError: libjasper.so.1: cannot open shared object file: No such file or directory.

So now I'm wondering whether following the info-box(on this page: https://devcenter.heroku.com/articles/postgis#geodjango-setup) which ultimately points to this miniconda on heroku example app, is an absolute necessity in order to make Geodjango on heroku work. Has this been the case for you @jodal?

[dschep]

Ooh.. I didn't realize heroku now could just use docker images. that should make things easier.

[dschep]

Woohoo. Tested out Heroku's Docker support. Soooo much easier!! I'm officially abandoning my fork of this buildpack. Buildpacks suck. This replaces the use of heroku/python, TrailStash/heroku-geo-buildpack and TrailStash/heroku-buildpack-maxmind.

$ rm Procfile
$ heroku container:login
$ cat > Dockerfile << EOF
FROM python:3

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

ENV DJANGO_SETTINGS_MODULE=my_django_project.settings \
    PYTHONPATH=/usr/src/app SECRET_KEY=1 DATABASE_URL=

# download GeoIP database
RUN wget -qO- http://geolite.maxmind.com/download/geoip/database/GeoLite2-City.mmdb.gz \
    | gunzip > /srv/GeoLite2-City.mmdb   
env GEOIP_PATH=/srv/GeoLite2-City.mmdb

# debian packages: GeoDjango dependencies
RUN apt-get update && \
    apt-get install -y binutils libproj-dev gdal-bin && \
    rm -rf /var/lib/apt/lists/*

# python packages
COPY requirements.txt /usr/src/app/
RUN pip install --no-cache-dir -r requirements.txt

# django apps & manage
COPY my_django_project /usr/src/app/my_django_project
COPY my_django_app /usr/src/app/my_django_app
COPY my_other_django_app /usr/src/app/my_other_django_app
COPY manage.py /usr/src/app/manage.py

RUN ./manage.py collectstatic --no-input

# Heroku doesn't like EXPOSE                                                                                   
#EXPOSE 8000

CMD gunicorn my_django_project.wsgi:application --bind=0:$PORT --access-logfile=- --error-logfile=-
EOF
$ heroku container:push web

[simonfromla]

@dschep Hey, question about your dockerized django proj on Heroku: did you end up needing a heroku.yml? Seems no matter what I do(even copying your Dockerfile), my heroku run bash shell won't ever show the newly deployed files/dirs.

Mind sharing a bit on how you got your image on Heroku?

[dschep]

Hey @simonsterj. Nope, I don't have a heroku.yml. I also had to log into the container registry with heroku container:login. When switching to this, you no longer deploy using git push heroku master but rather the heroku container:push web command is how you deploy.

This is the documentation I followed to get it working: https://devcenter.heroku.com/articles/container-registry-and-runtime

[goinnn]

I fixed it today with this changes:

[tworide]

@goinnn Worked for me as well. Thanks

[morenoh149]

I'm currently trying out heroku-18. Have folks abandoned this build pack for docker? or would a PR for @goinnn changes be accepted?

oh it seems like the generic python heroku build pack has the geospatial libs? heroku/heroku-buildpack-python#752 I'll be trying this out

[zachmccormick]

@morenoh149 I've been having good luck using the official buildpack for a while. Someone normally pings me when the geospatial libs break on that buildpack and I normally have it fixed on the next weekend :D

edit: it normally doesn't break unless someone upgrades the distro version, which normally just requires a reshuffling of includes/lib paths

[morenoh149]

@zachmccormick yes, I didn't report back but I now have geodjango running on heroku with the default python build pack. A related SO answer I made https://stackoverflow.com/a/53509910/630752

[jrae]

This helped me out when my rails server kept failing to deploy

https://www.diowa.com/blog/heroku/2017/08/01/using-rgeo-with-geos-on-heroku-with-apt-get

I think it was moving these two to the top of my Apt file

libproj-dev
libgeos-dev

And moving the "https://github.com/heroku/heroku-buildpack-apt" to be the first build pack

Now I can deploy again..