Use with Heroku?

6 views
Skip to first unread message

Michael

unread,
Oct 2, 2009, 8:10:57 AM10/2/09
to calendar_date_select
Hi All,

Has anyone had any luck using this gem on Heroku? Seems like the
conflict is between the gems 'blank_iframe.html' file and Heroku's
read-only file system. When an app is pushed to Heroku, it complies
the source into a "slug," automatically installs all specified gems,
and apparently executes the code in the calendar_date_select gem that
copies the javascript, css assets and this blank_iframe.html file in
to the public/ directory. When this occurs, heroku throughs an
exception and prevents the app from starting properly.

Has anyone else experienced this? Found a successful work-around?
According to the Heroku documentation, only the tmp/ and log/
directories are writable.

I am using AWS S3 as an asset store, which is the recommended
(preferred) method and I thought about forking the gem, wrapping the
code that copies the assets into the public/ directory in a
conditional statement checking RAILS_ENV, suppressing it when in a
production environment. We should probably add an initializer which
would allow a flag to be set indicating whether or not the production
environment is Heroku.

Any thoughts you have would be great. Thanks in advance.

- Mike

Tim Harper

unread,
Oct 2, 2009, 9:53:30 AM10/2/09
to calendar_d...@googlegroups.com

I'm pretty sure that if the public/calendar_date_select/calendar_date_select.js file exists, it won't try and install the assets (so you should commit it to your source control). May need to double check to see if blank.html follows the same rule.

Michael

unread,
Oct 2, 2009, 10:48:42 AM10/2/09
to calendar_date_select
Thanks for the feedback Tim,

You're right, it does verify that calendar_date_select.js is present
in the public/ directory. The problem for me is that I have
configured action controller under production environments to look to
AWS as the asset host, not the public directory. I have also
excluded the public/javascripts, public/stylesheets, public/images
directories from SCM, so when I push to heroku calendar_date_select.js
will never show up, automatically triggering the installation of local
assets (and throwing the exception).

It is kind of an ugly hack, but I suppose I could allow public/
javascripts/calendar_date_select/calendar_date_select.js to be under
SCM so that it is pushed with each remote commitment and just never
reference it under the production environment, thereby suppressing the
copy action. All of my javascript_include_tag, stylesheet_link_tag,
and image_* would all point to AWS and the local copy of
calendar_date_select.js would be "invisible".

My thoughts where to add a getter and setter method to the
CalendarDateSelect module that would allow for configuration under
remote asset stores. Maybe the setter would accept a simple boolean?
The code that copies the asset locally could be wrapped in a
conditional statement that checks to see if RAILS_ENV is set to
"production" and that the getter method returns true. This might be
flexible enough to allow development under localhost using the local
assets and then the option to use local or remote asset stores in
production. Your thoughts?

I wonder if industry best practices will fully endorse remote asset
stores over local ones, in which case problems like this one may
become more prevalent.

- Mike

P.S. Thanks for commenting in your source and great project by the
way.

On Oct 2, 7:53 am, Tim Harper <timchar...@gmail.com> wrote:
> I'm pretty sure that if the
> public/calendar_date_select/calendar_date_select.js file exists, it won't
> try and install the assets (so you should commit it to your source control).
> May need to double check to see if blank.html follows the same rule.
>

Tim Harper

unread,
Oct 2, 2009, 11:06:04 AM10/2/09
to calendar_d...@googlegroups.com
Thanks Mike,

I would be happy to accept a patch for that change.  It's been brought up before.  If you can't get to it, I may eventually, but it should be pretty easy to do.

Tim

Michael

unread,
Oct 2, 2009, 11:13:30 AM10/2/09
to calendar_date_select
Great! Would you like me to submit a ticket? I can start work on that
soon enough.

On Oct 2, 9:06 am, Tim Harper <timchar...@gmail.com> wrote:
> Thanks Mike,
> I would be happy to accept a patch for that change.  It's been brought up
> before.  If you can't get to it, I may eventually, but it should be pretty
> easy to do.
>
> Tim
>

Tim Harper

unread,
Oct 2, 2009, 12:03:25 PM10/2/09
to calendar_d...@googlegroups.com
If you want to submit a ticket, go for it. Not required though. Pull request on github would be suffice.

Tim
Reply all
Reply to author
Forward
0 new messages