cyberdelia / heroku-geo-buildpack

Geo libraries for Heroku
https://github.com/heroku/heroku-geo-buildpack
113 stars 135 forks source link

Update rgeo native extension build arguments #34

Closed woahdae closed 7 years ago

woahdae commented 8 years ago

Previously, the rgeo build silently failed due to not being able to link against required libraries. This is due to silently accepting but ignoring the previously valid --with-geos-dir and friends.

At some point the option changed to --with-opt-dir plus needing --with-geos-config, and this changes the build to reflect that.

This was deployed successfully with Ruby 2.1.2, Cedar 14, geos 3.4.2, rgeo 0.5.2, and bundler 1.9.7.

woahdae commented 8 years ago

Possible fix for #30 and #23.

tagliala commented 8 years ago

Hi,

I've tried this here: https://github.com/tagliala/rails-rgeo-geos/tree/rgeo-0.5.3-alt-buildpack

but I'm still not able to make rgeo find geos

remote: =====> Downloading Buildpack: https://github.com/woahdae/heroku-geo-buildpack.git
remote: =====> Detected Framework: geos/gdal/proj
remote:        Using geos version: 3.4.2
remote:        Using gdal version: 1.11.1
remote:        Using proj version: 4.8.0_1
remote: -----> Fetching and vendoring geos
remote: -----> Fetching and vendoring gdal
remote: -----> Fetching and vendoring proj
remote: -----> Vendoring geo libraries done
[...]
remote:        Installing rgeo 0.5.3 with native extensions
$ heroku run console
Running console on evening-atoll-64550... up, run.7453
Loading production environment (Rails 4.2.5)
irb(main):002:0> RGeo::Geos.supported?
=> false
tagliala commented 8 years ago

@woahdae thanks!

I was able to fix the buildpack I'm using with your code, with a small change (--with-opt-lib instead of --with-opt-dir). You can see the code here: https://github.com/tagliala/heroku-buildpack-rgeo-prep/commit/2b9dc763b4c359f3a7d9552ec7c92b48e100387d

How can I credit you?

https://github.com/tagliala/rails-rgeo-geos/tree/rgeo-0.5.3-alt-buildpack

remote:        Installing rgeo 0.5.3 with native extensions
$ heroku run console
Running console on evening-atoll-64550... up, run.5970
Loading production environment (Rails 4.2.5)
irb(main):001:0> RGeo::Geos.supported?
=> true
tagliala commented 8 years ago

My solution doesn't work anymore. Don't know exactly why :\

edit:

https://github.com/diowa/heroku-buildpack-rgeo-prep/blob/master/bin/compile#L14

This one apparently works. https://github.com/rgeo/rgeo/issues/125#issuecomment-189271915

edit 2:

Sorry, this PR works for me too.

https://intense-depths-97458.herokuapp.com/

Mr0grog commented 8 years ago

I started experiencing this same issue recently (upgrading a client who had long been on a very old version of RGeo and Geos). This PR seems to work, so it'd be great to see it merged in.

kofronpi commented 8 years ago

I'm confused on how to properly deploy postgis-related buildpacks as of now. Most methods explained use the deprecated multi-buildpacks buildpack and/or the deprecated BUILDPACK_URL, moreover I can't get them to work (RGeo::Geos is nos supported). any advice @cyberdelia ?

tagliala commented 8 years ago

@kofronpi

https://github.com/diowa/ruby2-rails4-bootstrap-heroku/tree/heroku-rgeo-geos-proj

Let me know if it works for you

Via app.json (Deploy to Heroku button)

Relevant code in app.json

  "buildpacks": [
    {
      "url": "https://github.com/diowa/heroku-buildpack-rgeo-prep.git"
    },
    {
      "url": "https://github.com/peterkeen/heroku-buildpack-vendorbinaries.git"
    },
    {
      "url": "heroku/ruby"
    }
  ]

.vendor_urls

https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz
https://s3.amazonaws.com/diowa-buildpacks/proj-4.9.1-heroku.tar.gz

Live demo: https://flannel-inuksuk-95052.herokuapp.com/


Via console

$ heroku create arctic-beaver-29213 --remote heroku-rgeo
$ heroku buildpacks:set https://github.com/diowa/heroku-buildpack-rgeo-prep.git --app arctic-beaver-29213
$ heroku buildpacks:add https://github.com/peterkeen/heroku-buildpack-vendorbinaries.git --app arctic-beaver-29213
$ heroku buildpacks:add heroku/ruby --app arctic-beaver-29213
$ heroku config:set LD_LIBRARY_PATH=/app/lib --app arctic-beaver-29213
$ git push heroku-rgeo heroku-rgeo-geos-proj:master

Check the proper order of buildpacks:

$ heroku buildpacks --app arctic-beaver-29213
=== arctic-beaver-29213 Buildpack URLs
1. https://github.com/diowa/heroku-buildpack-rgeo-prep.git
2. https://github.com/peterkeen/heroku-buildpack-vendorbinaries.git
3. heroku/ruby

Live demo: https://arctic-beaver-29213.herokuapp.com/


References https://devcenter.heroku.com/articles/buildpacks https://devcenter.heroku.com/articles/using-multiple-buildpacks-for-an-app https://devcenter.heroku.com/articles/app-json-schema#buildpacks

kofronpi commented 8 years ago

@tagliala thanks ! I carefully followed your instructions on a brand new app.

I have this result:

irb(main):001:0> RGeo::CoordSys::Proj4.supported?
=> false
irb(main):003:0> RGeo::Geos.supported?
=> true

This is an improvement... but, any idea why Proj4 is not supported while Geos is ?

thanks again for your help! :+1:

EDIT : apparently in my logs it's not vendoring proj4, I don't know why. My .vendor_urls file:

https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz
https://s3.amazonaws.com/diowa-buildpacks/proj-4.9.1-heroku.tar.gz

The heroku build log output:

-----> Fetching set buildpack https://github.com/diowa/heroku-buildpack-rgeo-prep.git... done
-----> heroku-buildpack-rgeo-prep app detected
-----> Removing cached .bundle/config
       Writing new .bundle/config
-----> Fetching set buildpack https://github.com/peterkeen/heroku-buildpack-vendorbinaries.git... done
-----> VendorBinaries app detected
-----> Found a .vendor_urls file
       Vendoring https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz
-----> Using set buildpack heroku/ruby
-----> Ruby app detected
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.3.1
tagliala commented 8 years ago

Yes, look like it's not using the proper .vendor_urls

-----> Found a .vendor_urls file
       Vendoring https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz

My logs show

-----> Found a .vendor_urls file
       Vendoring https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz
       Vendoring https://s3.amazonaws.com/diowa-buildpacks/proj-4.9.1-heroku.tar.gz

(you can try by yourself with the push to deploy button on the previous link)

Please note that at this point you will need to recompile the rgeo gem to enable proj4. You could go back to 0.5.1, deploy and update again to 0.5.3 or use the heroku repo plugin

edit: using 0.5.1 since 0.5.2 does not compile on Heroku

kofronpi commented 8 years ago

I have no explanation for the .vendor_urls file. I will investigate.

EDIT: found: https://github.com/peterkeen/heroku-buildpack-vendorbinaries/pull/6/files

Please note that at this point you will need to reinstall the rgeo gem. You could go back to 0.5.2, deploy and update again to 0.5.3 or use the heroku repo plugin

I don't really understand why ?

tagliala commented 8 years ago

I don't really understand why ?

...correct me if I'm wrong...

Because bundled gems are cached, so if you compiled rgeo 0.5.3 without the PROJ.4 native extensions, you will keep using that gem

Let's say I'm adding rgeo to my gemfile and geos to my .vendor_urls

During the first deploy, I will see:

[...]
remote: -----> Found a .vendor_urls file
remote:        Vendoring https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz
remote: -----> Using set buildpack heroku/ruby
[...]
remote:        Installing rgeo 0.5.3 with native extensions

Result: image


Let's see what happens if I add proj4 to my .vendor_urls

$ git log -p -1
commit 42621cd55db92093e67e974907fcc26c8fd6aa73
Author: Geremia Taglialatela
Date:   Fri Jul 1 18:43:35 2016 +0200

    Add PROJ.4 to vendor urls

diff --git a/.vendor_urls b/.vendor_urls
index 22cac36..c9ece56 100644
--- a/.vendor_urls
+++ b/.vendor_urls
@@ -1 +1,2 @@
 https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz
+https://s3.amazonaws.com/diowa-buildpacks/proj-4.9.1-heroku.tar.gz

During the second deploy, since rgeo's entry in Gemfile.lock is untouched, I will get instead:

[...]
remote: -----> Found a .vendor_urls file
remote:        Vendoring https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz
remote:        Vendoring https://s3.amazonaws.com/diowa-buildpacks/proj-4.9.1-heroku.tar.gz
remote: -----> Using set buildpack heroku/ruby
[...]
remote:        Using rgeo 0.5.3

Result: image

Again, trying 0.5.1

$ git log -p -1
commit 7b4260f468add6f70a89c7b1b6a0cb1a3152a0f8
Author: Geremia Taglialatela
Date:   Fri Jul 1 18:49:51 2016 +0200

    Use rgeo 0.5.1

diff --git a/Gemfile b/Gemfile
index 5db710a..295183a 100644
--- a/Gemfile
+++ b/Gemfile
@@ -3,7 +3,7 @@ source 'https://rubygems.org'
 ruby '2.3.1'
 gem 'rails', '4.2.6'

-gem 'rgeo'
+gem 'rgeo', '0.5.1'

 # Servers
 gem 'puma'
diff --git a/Gemfile.lock b/Gemfile.lock
index b76fb20..5004408 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -188,7 +188,7 @@ GEM
       thor (>= 0.18.1, < 2.0)
     rainbow (2.1.0)
     rake (11.2.2)
-    rgeo (0.5.3)
+    rgeo (0.5.1)
     rspec (3.4.0)
       rspec-core (~> 3.4.0)
       rspec-expectations (~> 3.4.0)
@@ -327,7 +327,7 @@ DEPENDENCIES
   rack-timeout
   rails (= 4.2.6)
   rails_12factor
-  rgeo
+  rgeo (= 0.5.1)
   rspec
   rspec-rails
   rubocop

Log:

[...]
remote: -----> Found a .vendor_urls file
remote:        Vendoring https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz
remote:        Vendoring https://s3.amazonaws.com/diowa-buildpacks/proj-4.9.1-heroku.tar.gz
remote: -----> Using set buildpack heroku/ruby
[...]
remote:        Installing rgeo 0.5.1 with native extensions
[...]
remote:        Removing rgeo (0.5.3)

Revert last commit and push force

Log:

[...]
remote: -----> Found a .vendor_urls file
remote:        Vendoring https://s3.amazonaws.com/diowa-buildpacks/geos-3.5.0-heroku.tar.gz
remote:        Vendoring https://s3.amazonaws.com/diowa-buildpacks/proj-4.9.1-heroku.tar.gz
remote: -----> Using set buildpack heroku/ruby
[...]
remote:        Installing rgeo 0.5.3 with native extensions
[...]
remote:        Removing rgeo (0.5.1)

Result: image

kofronpi commented 8 years ago

@tagliala thanks, you have been really helpful: it works now ! :+1:

kunalbhatt commented 8 years ago

can we merge this?

ConorNugent commented 8 years ago

Hi guys, I was just wondering what the status of this pull request is? I ran into issues trying to run a migration on heroku after installing the master build of this buildpack. I get

undefined methodst_polygon' for #ActiveRecord::ConnectionAdapters::PostgreSQL::TableDefinition:0x007f25cacedaf0`

I'm not sure if this is directly related to the buildpack but it might point an issue with latest version of activerecord-postgis-adapter and heroku. Maybe?

Also looking at the console I get
irb(main):002:0> RGeo::CoordSys::Proj4.supported? => false irb(main):003:0> RGeo::Geos.supported? => false

Should I go with https://github.com/diowa/heroku-buildpack-rgeo-prep for the time being? Also, just a heads up the heroku postgis docs still points at the master of this buildpack. Maybe it might be worth putting a warning on the README? Sorry for pointing out possible issues. I know a lot of effort goes into these things and I know that I, for one, really appreciate it

tagliala commented 8 years ago

@ConorNugent sorry, I don' know if that issue is related to the buildback but give a try to our buildpack at diowa. There is also a blogpost: http://www.diowa.com/blog/heroku/2016/02/26/using-rgeo-with-geos-on-heroku

ConorNugent commented 8 years ago

hi @tagliala ! that worked great. I added in the proj4 vendor file and made sure to tweak the rgeo version number to ensure rgeo is installed from scratch and boom!

' irb(main):001:0> RGeo::CoordSys::Proj4.supported? => true irb(main):002:0> RGeo::Geos.supported? => true`

I'm still running into an error when I try to run my migration

undefined method st_polygon' for #ActiveRecord::ConnectionAdapters::PostgreSQL::TableDefinition:0x007f25cacedaf0

but I suspect this is possibly an adapter/postgis version issue and I'll dig into this separately. Do you think it might be worth letting the guys at heroku know about the issues with this buildpack so they can update their documentation? I'm happy to

tagliala commented 8 years ago

Do you think it might be worth letting the guys at heroku know about the issues with this buildpack so they can update their documentation? I'm happy to

Yes, you could try the Feedback option at the bottom of the article and tell them about this thread. They are usually very responsive

ConorNugent commented 8 years ago

Done! Thanks again for your help

ivar commented 7 years ago

This buildpack is still the recommended one for rgeo based applications on Heroku but the caveat is that this PR should be merged first. This doesn't appear to be in master yet so I'm a bit confused as to what's required to actually do the merge? Is there something I can help with? Is there a reason for the lack of merge? In the meantime, what is the best option - using diowa's buildpack or whoadae's branch?

tagliala commented 7 years ago

@ivar iirc, this buildpack bundles proj + geos +gdal. Our buildpack at diowa takes advantage of vendorbinaries buildpack, so you can only install geos (or proj). I didn't test that buildpack with GDAL.

Also, I'm going to provide updated vendor binaries for Geos 3.6.1 and proj.4 4.9.3

tagliala commented 7 years ago

Hi everyone,

I've updated the vendor binaries

https://s3.amazonaws.com/diowa-buildpacks/geos-3.6.1-heroku.tar.gz
https://s3.amazonaws.com/diowa-buildpacks/proj-4.9.3-heroku.tar.gz

as well as the before mentioned blog post. Let me know if you need further information