We are looking into building a very large rails application and considering using engines for better separation of "modules" out of the main app.
we have started this process by creating a small engine using the gem motorhead (the idea of its active_if component is wanted).
That engine was then removed from the main app and given a git init, then pushed to github.
the main app then was able to pull the gem in within the Gemfile.
During this proof of concept, it works, but not very efficient, and also updating the new engine/gem is a bit awkward in this way as it is kinda a submodule in a way. What is the proper workflow for building and maintaining engines/gems when building a modular app like this?
Thanks in advance
The most akward part about deploying Gems or Engines as modules is the constant need to update. We had a lot of success with using:
bundle config local.my_gem ~/projects/my_gem/
It'll point to the Gem/Engine version on disk without modifying the Gemfile and Gemfile.lock.
To remove the local override run:
bundle config --delete local.my_gem ~/projects/my_gem/
With this you should be able to restrict the times the Gemfile.lock has to be updated to deployment time.
Related
I'm developing a main rails application where I want to mount some rails engines and gems I've developed on my own.
Some of my (under development) engines depend on the main Application and the engines I've already mounted into the main app.
Now, I want to test, if my engine which is under development also works in my main application together with the already mounted engines and gems.
If I want to test it now, I must commit every singe change with git and install the gem / engine via a GitHub repository in the main app.
Is there a better way to test changes of your engine without having to pollute the git commit history / without commiting every single change and install it via a git repository?
Can I mount my engine locally into the main app, change something and it will be immediately available in the main app?
In your Gemfile, you can point gems to your local working copies:
gem 'my_gem', :path => '/my/workspace/my_gem'
See http://bundler.io/v1.3/man/gemfile.5.html#PATH-path-
general question that can be used in many different situations, so I thought it would be interesting to ask.
I'm semi new to Ruby and am learning from Treehouse. I am doing the social media site project, and am about half way through.
I was hoping to set up a separate installation from the source files they give you, of the completed site, to do a simple compare and contrast, and really I am just curious as to what the final product is gonna be like.
My question is, is there an easy way to just grab their files, install all the gems and dependencies and run the rails server. If I just try to run the server on the folder, I get a bunch of errors about Gems not being installed and such, which is expected.
If anyone has a process they use when doing things like migrated entire environments from one location to another, it would be appreciated!
Go to project directory.
Install all of the required Gems by executing
bundle install
Create database by executing
rake db:create
Then migrate the database by executing
rake db:migrate
And finally run the application using
rails s
If you have cloned their repository, or copied the files to a folder, try running
bundle install
from the command line
I am experimenting with a design for a Rails application which will have most of its functionality delegated to highly specialized Engines. However, there will probably be 10 Engines or so and I definitely don't want to have to manage 10 different gems and Git repositories.
Rails and RefineryCMS both seem to house all their submodules in one git repo but then somehow release them as independent gems as well as requiring them all with - in Rails' case - a simple require
'rails/all'.
I have of course browsed the source code but I could use a more experienced eye for help ... could anyone please enlighten me as to how this multi-gem, one-repo architecture works?
It's very simple, at http://github.com/resolve/refinerycms there is a folder for each gem. In those folders you will find a gemspec, so building the gems is as simple as cd-ing into those directories and running gem build.
Then, the main https://github.com/resolve/refinerycms/blob/master/refinerycms.gemspec simply lists all these other gems as dependencies.
Trying to understand this open source app on github, it has a gem file:
https://github.com/bestbuyremix/BBYIDX/blob/3f8d378ef318544411aa887c4ef71e1ab8a9efd0/.gems
And a plugins folder:
https://github.com/bestbuyremix/BBYIDX/tree/3f8d378ef318544411aa887c4ef71e1ab8a9efd0/vendor/plugins
Why would you want to do this? Does this make upgrading the plugins harder?
When you reference a gem, from what I understand, it downloads the files and stores them at a global level (gemset if using rvm etc), so I guess loading it as a plugin gives you access to the source to modify?
i.e Why go with gem versus a plugin or visa versa?
Plugins give you the flexibility of being able to just copy your app somewhere else and poof! it's all ready to go.
Gems on the other hand, force you to a) download them to every single piece of hardware that your app is running on via rake gems:install and b) force you to keep track of which packages are installed on which system.
With plugins, you know that when you stick it in your vendor directory, it will work immediately.
I like the idea of using submodules, but I am worried that I am leaving my code in someone else's hands. The main issue is that every time I deploy with capistrano, a new copy of the submodule is checked out since I am using:
set :git_enable_submodules, 1
So what happens if someone commits broken code? Then I app breaks on deploy.
Are submodules generally a bad idea unless you control the repository?
If so, is it common practice to just keep a copy of every plugin in your local repo and under your SCM?
Thanks!
Yes, you should keep local copies of everything that may be updated without warning (such as git submodules or svn externals). Take no risk when it comes to deployment on production!
Some even argue you should freeze Rails and all your pure-Ruby gems to the vendor directory as well, so that they only get updated when you want to. You avoid having to install all dependencies on every server you deploy to. This is slightly less relevant now that Rails makes it really easy to install all required gems with a simple rake task, though (rake gems:install).