search

gregwebs / haskell-heroku

Haskell helpers for deploying to Heroku
BSD 3-Clause "New" or "Revised" License
18 stars 6 forks source link

Parse Port from DATABASE_URL #5

Closed cpytel closed 10 years ago

cpytel commented 10 years ago

Heroku Postgres uses the default port for its default database, but Heroku production databases do not use the default port.

As specified in the note here: https://devcenter.heroku.com/articles/upgrade-heroku-postgres-with-pgbackups#promote-new-database

Please take care to note that the port number for your database may change during this process. You should ensure that the port is parsed correctly from the URL.

gregwebs commented 10 years ago

Thanks!

cpytel commented 10 years ago

Thanks for the quick merge, would you be able to push a new version of the package? We're currently blocked from using this in production.

gregwebs commented 10 years ago

It seems that the port has a colon in front of it right now, should that be removed?

You need to be able to use github sources instead of only hackage to avoid getting blocked. The easiest way to do that is to use a sandbox and run cabal sandbox add-source.

cpytel commented 10 years ago

Sorry about that, good catch, I didn't see that when I checked. I've fixed that and created another pull request https://github.com/gregwebs/haskell-heroku/pull/6

pbrisbin commented 10 years ago

You need to be able to use github sources instead of only hackage to avoid getting blocked. The easiest way to do that is to use a sandbox and run cabal sandbox add-source.

How do you see this working in a Heroku (or any remote) deploy? I.e. where we push our sources up to a Heroku remote and it runs cabal install there.

gregwebs commented 10 years ago

building on Heroku seems like a tenuous strategy to begin with. When I was using Heroku I just pushed a binary that was built elsewhere. But doesn't it just use a buildpack that you can change?

pbrisbin commented 10 years ago

building on Heroku seems like a tenuous strategy to begin with.

I'm starting to agree.

When I was using Heroku I just pushed a binary that was built elsewhere

The trade off of maintaining that elsewhere is what has us hanging on to traditional Heroku deploy methods so far. Though it is something we continue to consider.

But doesn't it just use a buildpack that you can change?

We've had to do a lot of customizing so far to get things like coffee script compilation working, etc. Customizing just to deal with a temporary dependency need would work, but doesn't seem worthwhile when the issue is so infrequent and devs like you respond so quickly!

Anyway, thanks for your input.