Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Rails Constant #129

tongueroo opened this issue Jan 5, 2019 · 4 comments


Copy link

commented Jan 5, 2019


In a Jets application, the Rails constant is currently defined. Requesting to remove the Rails constant.


The reason it would be good to remove this constant is that other gems, libraries, and plugins check for the Rails constant to infer that it's in a Rails app and perform some Rails specific logic. Having the Rails constant defined in a Jets application results in not being able to use these libraries in Jets applications. Being able to use these libraries would be a huge benefit.


Guide-level explanation

Remove the Rails constant.

Reference-level explanation



Jets uses Rails to do some heavy lifting like rendering. This is one of the reasons why Rails is currently defined. Some of the ActionView code defines it. So it's a decent amount of work, but think it's still worth it though!

Unresolved Questions

Will have to dig into this to figure out the issues and let it simmer on the brain for a bit.

@tongueroo tongueroo added the feature label Jan 5, 2019


This comment has been minimized.

Copy link

commented Jan 6, 2019

Hi @tongueroo,

maybe it's not necessary to remove Rails constant. Maybe you could just delegate some methods of Rails to Jets. I've been trying some things with Dynamoid: when it detects Rails constant, it tries to call Rails.application and Rails.env (, and, after that, it tries to use Rails::Railtie (

I tried to define the following before loading dynamoid:

module Rails
  def self.application

  def self.env

  class Railtie
    def self.rake_tasks

It prevents errors in dynamoid but also cause errors in deployment:

10:20:55AM UPDATE_FAILED AWS::CloudFormation::Stack JetsPublicController Embedded stack arn:aws:cloudformation:eu-central-1:***:stack/jetsapp-dev-JetsPublicController-*** was not successfully updated. Currently in UPDATE_ROLLBACK_IN_PROGRESS with reason: The following resource(s) failed to update: [ShowLambdaFunction]. 
10:21:06AM UPDATE_FAILED AWS::CloudFormation::Stack JetsPreheatJob Resource update cancelled

This comment has been minimized.

Copy link
Owner Author

commented Jan 7, 2019

@jalerson Maybe. Think it'll be great if it ends up working by delegating Rails to Jets for the specific case of Dynamoid 😁

Wondering what the error at the child stack is. Currently, the logging only shows the parent stack events. I usually look at the CloudFormation console to see what the error is on the child stack. Maybe it's an error that I might know off the bat.

Think for the general case, it's probably best to get rid of the Rails constant. It'll handle the rest of the gems. 🧐


This comment has been minimized.

Copy link
Owner Author

commented Jan 8, 2019

@jalerson Another idea to workaround until I have more time to look at this is fork the dynamoid gem and comment out the Rails logic. Then you can include the forked dynamoid gem to your specific project like so


gem "dynamoid", git: "", branch: "master"

Understand it might not be ideal, so it's just an idea to help unblock you. Will dig into this more though!


This comment has been minimized.

Copy link
Owner Author

commented Jan 11, 2019

Released in v1.5.0 CHANGELOG

@tongueroo tongueroo closed this Jan 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.