No. Fortunately this isn't an absolute requirement for me (yet), so I
decided to put it off in hopes that Heroku will update their bundler
system to respect the :production group.
On Sep 15, 10:02 am, Steve Odom wrote:
> Marcel,
>
> Did you ever figure out a hack to haver bundler recognize your o
Marcel,
Did you ever figure out a hack to haver bundler recognize your osx
platform?
Steve
--
You received this message because you are subscribed to the Google Groups
"Heroku" group.
To post to this group, send email to her...@googlegroups.com.
To unsubscribe from this group, send email to
h
BUNDLE_WITHOUT is broken in bundler itself:
http://github.com/carlhuda/bundler/commit/617fbc3661c56a79682d571c168ba8d68c1c3453
On Sep 10, 6:57 pm, marcel wrote:
>
> I added autotest-fsevent to the :development group in my gemfile, and
> added BUNDLE_WITHOUT=test:development to the heroku app conf
I tried Pasha's suggestion, but it looks like the environment variable
is ignored by bundler in heroku.
I added autotest-fsevent to the :development group in my gemfile, and
added BUNDLE_WITHOUT=test:development to the heroku app config. But
when I pushed, heroku still tried to build the native ex
You can use ENV vars to config default bundler behavior. Here is my
solution of this problem:
http://chipiga.pp.ua/ruby/bundler-on-heroku-and-without-feature/
On Sep 5, 2:29 am, Gabriel wrote:
> It seems like you could use bundle groups and then use 'bundle package
> --without dev_test_gems' to c
It seems like you could use bundle groups and then use 'bundle package
--without dev_test_gems' to create a local cache of just your
production gem dependencies. Remember to check your Gemfile.lock file
into git and then git push to heroku.
Heroku will then use 'bundle install --deployment' which
On 1 Sep 2010, at 06:42, Gabriel wrote:
> Maybe I'm missing something obvious, but can't you specify a group for
> those gems and then only deploy them in dev and test? So as part of
> your deployment to heroku you'd do something like: bundle install --
> without gems_heroku_dun_like
>
> I'm go
Maybe I'm missing something obvious, but can't you specify a group for
those gems and then only deploy them in dev and test? So as part of
your deployment to heroku you'd do something like: bundle install --
without gems_heroku_dun_like
I'm going to have to deal with exactly the same problem so I
It's rolled out. Please file a support ticket if there are any issues.
Thanks,
Terence
On Mon, 2010-08-30 at 17:54 -0500, Terence Lee wrote:
> We're planning on doing a rollout for Bundler 1.0.0 to support Rails 3.
> As always, please test things locally and on production. You can view
> the fu
You're not alone -- would be great to have a solution for this.
Heroku's "official" stance is to just include them and don't worry
about the bloat, but obviously that won't work in your case.
On Aug 31, 2:32 pm, Ashley Moran
wrote:
> On 30 Aug 2010, at 23:54, Terence Lee wrote:
>
> > In the near
On 30 Aug 2010, at 23:54, Terence Lee wrote:
> In the near future we're going to start requiring the Gemfile.lock to be
> checked into your git repository since this is the recommended deploy
> path set by the bundler team. Please take the time to do so if you
> haven't already.
There's an unfo
We're planning on doing a rollout for Bundler 1.0.0 to support Rails 3.
As always, please test things locally and on production. You can view
the full changelog here:
http://github.com/carlhuda/bundler/blob/d2b83f536291239d0ce2d2d27fa3821beb7e11f5/CHANGELOG.md
In the near future we're going to st
12 matches
Mail list logo
