The rails engines feature is pretty good, and I have watched the Railcasts and read the Rails documentation on it. I can see how you can access or override all the relevant components in the engine.
However, say I wanted to drastically modify the engine's code, is it possible to convert the engine back into a normal Rails app, and then take it from there. Is there anything else involved other than copying the directories in the gem over an empty application directory?
I am looking at this engine:
https://github.com/ging/social_stream
Yeah you can, just go to https://github.com/rails/rails & hit the fork button to fork the repository to your github account (assuming you already have one setup). Afterwards, clone the forked project to your local machine with:
git clone your_forked_repository_url.git
If you don't feel the need to fork your own version run:
git clone git://github.com/rails/rails.git
At this point you can make modifications to your heart's content. To use a local copy of the gem in a rails application add the following to your Gemfile (replacing the old rails gem):
gem "rails", :path => "/somewhere/your_rails_project"
All of this and more is highlighted in http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html
Related
I am trying to understand the workflow for deploying a rails engine. I read this answer. But I don't fully understand what is going on between Gemfile, bundler, Capistrano and rails.
I have a situation where I am working on an app locally pushing to a git repository and using Capistrano to deploy. In my apps Gemfile
#gem 'my_engine', git: "git#myrepo.com/myengine.git"
gem 'my_engine', path: '/local/path/to/MyEngine'
When I am developing I often comment out the git repository and use my local( I know some may take issue with this but another time another question) what I want to know is:
when is the engine included or mounted?
If I am working with the local engine and decide to deploy the app is the local engine included at this point?
Would the local current branch/state be what is used?
If I decide to switch to the repo for production(and or dev) at what point is that included?
Does Capistrano run bundle install during the deployment?
Would Capistrano be able to use my local copy or would it need me to use the git repo?
Engine and Host application are in same repository then specifying
gem 'my_engine', path: '/local/path/to/MyEngine'
will work.
If you had different repository for engine and application then need specify gem as
gem 'my_engine', git: 'git#github.com:my_engine.git',
branch: 'master', revision: 'cb1a8d2495168d411676f58bdfc9015fe728948c'
branch and revision are optional but its recommended if you want to point it to specific commit or branch.
Make sure the deploy(user on server used to deploy application) user has access to engine repository.
I have two projects that are version controlled in their own respective private GitHub repositories.
One of them is a Rails app, and the other one is a Rails engine.
I do not want to expose the Rails engine as a public gem.
How can I declare my Rails app has a dependency on the engine in such a way that Heroku can resolve it?
You can use a private gem server like Gemfury. It is also a Heroku addon (free plan works fine for your case).
This way you'll be able to release versions of your gem. Works much like rubygems, but is private.
Assuming that your engine is a gem in a private Github repository, you can try this approach, which uses an OAuth token:
https://gist.github.com/masonforest/4048732
As noted in the comments, the version which involves hardcoding the OAuth token value in your Gemfile is less secure than using an environment variable.
You can vendor your engine by placing the source in the vendor folder, then in your Gemfile reference it by path:
# Gemfile
gem 'some_engine', path: 'vendor/some_engine'
Either directly copy-paste the source there, or use a Git submodule. Run bundle install and you should be set.
I have a Rails application that is pointing to a gem which is on github (not yet pushed to Ruby Gems) and it is not yet versioned so when I run bundle it looks like this:
gem (0.0.0) from git#github.com:company/gem.git (at master)
I have been working on changes to the gem and want to begin versioning it so when I push to master it doesn't break functionality in the Rails application that relies on the previous gem. I am not sophisticated enough to make the gem backwards compatible so I was thinking versioning would be the best way to handle this problem.
I am looking for advice on how to begin versioning this gem, is it simply changing the gemspec to 0.0.1 and then changing the gemfile in my Rails application to point to that?
As per semantic versioning, you should start off at 0.1.0 and increment the MAJOR version for any updates that are not backward compatible, the MINOR version if it only introduces new features but is backward compatible, and the TINY version if it's a bug fix or the like.
That said, if you are hosting via GitHub only, you can simply change the gemspec version to your preference as well as add a tag to that commit. Adding a tag makes it easy to find the correct version in GitHub after you've moved on to other versions - if using Bundler, for instance, your Gemfile entry would look like this:
gem 'your-gem', git: 'git://github.com/your-repo/your-gem.git', tag: 'v0.1.0'
You could also use the following (lengthy) set of commands to do this without bundler:
git clone git://github.com/your-repo/your-gem.git
cd your-gem
git checkout v0.1.0
gem build your-gem.gemspec
gem install your-gem-0.1.0.gem
If you intend to host via http://rubygems.org, you'll need to make yourself an account and then push your new version up to there. Rubygems will detect the version from the gemspec and provide it using the more standard Gemfile entry format:
gem 'your-gem', '=0.1.0'
Or using the gem command:
gem install your-gem -v '=0.1.0'
I am developing a Rails app that uses a gem that I am also developing.
Every change that I make in the gem I have to: build, uninstall previously installed gem, install built gem, restart rails app.
You can imagine that it easily becomes a nightmare to make even litle changes in the gem.
I´ve tried to manually load all files that are configured to be loaded by the gem (at Gemspec) but it always seem to be some problem in the loading process, not finding libraries or not loading in the proper order.
Is there a way to set my environment to better develop my gem with my app?
You can just add a file reference to your local filesystem in your Gemfile, like
gem 'new_gem', :path => '~/RubyPlayground/DevGems/new_gem/'
That way you just need a new bundle install after modifying your new gem.
Update
Reading your description again you might not be using rails 32. My suggestion is of course based on bundler at least.
You could always symlink your gem code to lib/ and then include that in your autoreload paths (application.rb IIRC).
I want to use the LinkedIn gem But not the one that I get when I type
sudo gem install linkedin
I want a specific one that somehow has done patches to. It is a fork of the original which is:
http://github.com/jbasdf/linkedin
I have downloaded sources from the above link, and use "rake" command to build a gem locally. So everything is working fine locally.
But now I have a question. How can I setup this folked gem on the server (engine yard)? I am not sure how to bild a gem on the server in this case.
Many thanks!
If the pre-built gem is available on a server(gem cutter) you should be able to use Trip's method.
If not two options spring to my mind:
1) Write a chef script that clones the source from github and builds it.
2) Use bundler with its built in support for building gems from a git url. EY fully supports bundler.
I think the latter would be a better choice, as it completely removes the need to use EY's UI for managing gems and is a step towards Rails 3 compatibility.
You can log into EY's cpanel. On your dashboard, Click "Application" in your instance, and then click on the Ruby Gem Icon. In this panel you can download gems to install on your server including what version you want them as well.