I have written some Rails API little long ago. I used namespace,module for making different versions of it.
Now I need to move my APIs to next version. Where I need to use different gems to achieve the requirement(need to add and delete some extra gems). While keeping the present version running for some more time.
I can use namespace, modules for routes and business logic changes. But how can I specify different gems for this version of API?
Does creating a separate git branch is the solution?
or
should I use different Gemfile.
How should I achieve this?
In same application if you want to add a new Gemfile, then I think it will be better option to create a engine and keep it inside vendors folder, so it will be inside your application and you will get separate routes, namespaces and Gemfile for that.
You can check the link given below about engine development.
http://guides.rubyonrails.org/engines.html
Related
How do I create a gem project nested inside my current Rails project?
I've got a Rails project with several parts that could easily be gems. I would like to extract these parts into gems but not leave the current Rails project. Creating new source control repos for the gems add additional complexity that project or organization is not ready or able to handle. These complexities will be overcome at some point and I would like to be ready.
So far I can only think of these items.
Relocate code to a single directory root. I'm guessing this would be in the vendor path
Create a <something>.gemspec
Link to the gem in the Gemfile of the Rails app
gem 'my_lib_code', path: 'vendor/my_lib_code'
What else do I need to do? I'm sure I'm missing something important.
If this were a c project I would create another shared library that the make process spits out. Or if this where a c# project I would make a .dll. For Java I would...
I'm sure Ruby can do the same as all the other languages. Something that is a half way step between a normally fully extracted gem and just some code siting in my lib path.
This is a perfectly fine approach for a component-based architecture.
You have a single repository, a single test suite, and a single deployment process, while at the same time you are "forced" to think of clean interfaces and separation of concerns.
Of course if you are planning on sharing this functionality with other projects, an externally hosted (but not necessarily public) Gem would serve better.
Implementation wise, you can get some nifty ideas from Stephan Hagemann's talk at this year's RailsConf: "Get started with Component-based Rails applications!"
I have a number of view helpers I use on almost every project, a set of useful rake tasks, minor extensions to active record, extensions to some gems (inherited_resources).
I'm wondering, what would be a good way to manage these 'snippets'? I wouldn't want to manage a gem for each snippet, or even a gem for each 'type' of snippet. Would it suffice to bundle this into a personal gem? Maybe add the option to specify which helpers/extensions to include in the project?
I could use a 'template' application which I could bundle with this code, but the problem here is if I update a snippet on one project, I want to be able to rollout that update on all projects with minimal effort (i.e. bundle update).
With your requirements, I would bundle it all in a base-zenph-gem and use it in every one o your projects, as it is the best way to have synchronized code over different projects.
Also, make a good documentation for it, as if anyone inherits one of those projects would love to know what is going on.
Instead of a gem with Rails you can create an engine which contains reusable functionality, then you can specify the use of the engine within your applications.
You can read more about it in the Rails documentation: Rails Engines
I have two rails apps that I am thinking about merging into one because they share a similar layout. Right now there is a script in one app that pulls the resources from the other app (including a base controller) into the second app. There are a few ways I have been thinking about doing this:
Merge the apps with namespaces and upon deploy have a script that creates two separate RPM packages (this is for deployment on CentOS/RHEL) with the appropriate files in it
Run one app as the engine of another. Put all the shared controllers and visual assets into the top-level app. Upon deployment rip rip out the engine if I don't need it. (i.e. if it is just the first app and I don't want to give the code of the second app)
Create a GEM with the common controllers and CSS/JS and find a way to inject it into each running app.
Any thoughts/ideas? I am thinking of going with number 1 as it will probably be the easiest for development (2 would be easier for deployment I think)
At Brighter Planet we do (3). Our shared layout gem supports both Rails 2 and Rails 3.
In particular you'll want to look at:
lib/brighter_planet_layout/rails.rb which helps Rails 2
lib/brighter_planet_layout/railtie.rb which helps Rails 3
lib/brighter_planet_layout/rake_tasks.rb which helps you copy shared files into Rails 2 public dirs
How about 4: make three engines (or gems, or engines encapsulated in gems): one for the common stuff, and one for each application's unique stuff?
Have you considered creating an engine with the common controllers, css, and js, then packaging the engine as a gem. When you are working locally, you can have both apps point to a shared development copy of the gem using bundler. To deploy, package the gem with each app, and deploy the whole thing. There are a lot of benefits to doing it as a gem, like the ability to have different versions of the gem in the future so you don't have to update both apps at the same time.
This seems like a pretty decent engines guide: http://www.themodestrubyist.com/2010/03/05/rails-3-plugins---part-2---writing-an-engine/.
I'd be very leery of it, and would probably go with the above approach, but you may consider using symlinks to permanently pull files into one or the other of the projects. I think it's a bad idea, but in some narrow cases it might make sense. It really depends on your exact situation since it's kind of a nasty hack, but nasty hacks can sometimes solve specific problems eloquently.
Most importantly, I'd recommend not merging the apps. The scenarios of modifying the package on deployment to separate the two apps is error prone, and counter to current quality control procedures-- you want the code you develop to match the deployed app as much as possible.
Given that, you want to look at the different modularity approaches. There are actually lots of options for sharing code:
gem
plugin
library code included with a git submodule or equivalent
rails engine
separate deployed app
Probably a shared engine packaged as a gem is the nicest way to go, but it requires you be on the right version of Rails to get the full benefit. Even without an engine, you can get this to work... it'll just take a little more setup.
By "separate deployed app", I mean a third application that has the shared functionality. This may be the needed resources (CSS, JS), and can even be portions of the pages (loaded dynamically). This is potentially a funky solution, but I've seen it work in the right situation.
And any of these solutions requires a bit more effort on the developers' part... but in the end it's better the deployment troubles you'd get by mergine the code bases
I have a set of functionality that I am considering packaging so as to use them in multiple projects, but I can't decide whether to choose a gem or a plugin. What is the difference? Which one should I choose?
Gem is currently acknowledged as the 'best practice' for Rails. (You can also package as a gem and include an install.rb so that your project can be optionally be installed as a plugin - see this Rails dispatch article).
Basically the only reason to go with a plugin is if your users will want to be able to modify the code more often than not, as it stores a copy in vendor/plugins. However, with the advent of bundler it's pretty simple to store your gems per repository as well and modify them.
If you go with gems, you get the advantages of dependencies, versions, and the functionality that rubygems.org offers for searching, alerts and so on.
Definitely make it a gem!
I'm starting research on what I'd need in order to build a user-level plugin system (like Wordpress plugins) for a Rails app, so I'd appreciate some general pointers/advice. By user-level plugin I mean a package a user can extract into a folder and have it show up on an admin interface, allowing them to add some extra configuration and then activate it.
What is the best way to go about doing this? Is there any other opensource project that does this already? What does Rails itself already offer for programmer-level plugins that could be leveraged? Any Rails plugins that could help me with this?
A plugin would have to be able to:
run its own migrations (with this? it's undocumented)
have access to my models (plugins already do)
have entry points for adding content to views (can be done with content_for and yield)
replace entire views or partials (how?)
provide its own admin and user-facing views (how?)
create its own routes (or maybe just announce its presence and let me create the routes for it, to avoid plugins stepping on each other's toes)
Anything else I'm missing?
Also, is there a way to limit which tables/actions the plugin has access to concerning migrations and models, and also limit their access to routes (maybe letting them include, but not remove routes)?
P.S.: I'll try to keep this updated, compiling stuff I figure out and relevant answers so as to have a sort of guide for others.
You might want to check out mephisto, it's a blogging software built with ruby on rails and has add-on plugin support. Not sure if it works how you are thinking of, but might give you some good insights. The source can be found on GitHub.
You should look at deface gem. It allows to customize rails views, adding content via hooks and replacing whole views/partials. Spree is using this gem so you can look also at spree. Beside views they also have other solutions for customizing application so you can find more answers to your questions.