Unpacking/Freezing Gems into a Non-Rails Ruby App

unpacking/freezing gems into a non-rails ruby app

UPDATE (New Solution):

Try Yehuda Katz's new bundler gem. gem install bundler then create a Gemfile with all your dependencies. See the documentation for more info.

Old Recommendation:

One easy way is to just manually unpack the gems into your vendor directory and add the lib path of the unpacked gems to the front of the $LOAD_PATH.

To unpack a gem:

$ cd vendor/gems
$ gem unpack active_support
Unpacked gem: '/path/to/myproject/vendor/gems/activesupport-2.3.2'

Just make sure you unpack all the necessary gems and their dependencies (using the correct versions).

To add all gems under vendor/gems to your $LOAD_PATH, try adding something like this to your application's initialization:

Dir.glob(File.join("vendor", "gems", "*", "lib")).each do |lib|
  $LOAD_PATH.unshift(File.expand_path(lib))
end

Update: Sarah (in the comments) convinced me it might also be necessary to override the GEM_PATH. Here's one way to do that:

require 'rubygems'
gem_paths = [File.expand_path(File.join("vendor", "gems")),  Gem.default_dir]
Gem.clear_paths
Gem.send :set_paths, gem_paths.join(":")

---

Another option is to look into Rip (Ruby’s Intelligent Packaging) for managing your dependencies. Rip looks really sweet, but it's still new.

Ruby gems in lib - spare tire principle

How about using bundler?

Then you can include a Gemfile that specifies all the necssary gems and just run "bundle install" on each machine to pull them down.

If you really want to bundle them with the app run "bundle package" and the gems will be stored in vendor/cache.

Is it considered a good practice to use ActiveSupport in non-Rails gems?

This is a really subjective call. While ActiveSupport does provide a number of useful date manipulation methods, including it just for that is extremely heavy-duty and can cause absolute chaos when included in projects that aren't expecting it. Some features, if enabled, like the auto-loader system, can change how require works and how missing classes are handled, in dramatic and unexpected ways.

If you're creating a project that's probably going to be paired with Rails or ActiveSupport anyway, it's probably not a big deal. If this is rarely going to be the case, you might want to simply re-implement the date methods in your own module so that there's no dependency.

Keep in mind that ActiveSupport does significant re-decorating to many core classes, so imposing that on people using your gem is perhaps making your gem a rather unruly guest.

There's also few things more annoying than getting stuck in dependency hell where one won't work with ActiveSupport newer than X and another won't work with a version as old as that, meaning there's no singular version that works at all.

How to setup application/ld+json schema.org meta data in rails 4 app

There is a JSON-LD gem (http://rubygems.org/gems/json-ld), but it might not be specifically what you're looking for. Note that the point of JSON-LD is that it's just JSON, in this case using the schema.org context to interpret the values. Assuming that your data is in ActiveRecord models, you'll need a way to make sure that the record properties correspond to the appropriate schema.org properties. If this were the case, then just serializing your model to JSON (#to_json) gets you most of the way there. What remains is to add the @context, @id, and @type fields to the JSON.

For example, say you have a User model which serialized to something like the following:

{
  "name": "Harry",
  "email": "Harry@example.org"
}

As both "name" and "email" properties of http://schema.org/Person, you could get partway there by simply adding a @context and @type as follows:

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "Harry",
  "email": "Harry@example.org"
}

Presuming that you're building a RESTful app, it's good practice to give every object an @id, which corresponds to the resource URL for this person. This could be like the following:

{
  "@context": "http://schema.org/",
  "@id": "http://example.com/people/harry",
  "@type": "Person",
  "name": "Harry",
  "email": "Harry@example.org"
}

Now, if you retrieve http://example.com/people/harry as JSON (or JSON-LD), you could get back that representation.

The other thing about JSON-LD is that it's for "Linked Data", so including references to other resources is useful for allowing them to be found, much as you probably do within your HTML. The schema.org documentation includes numerous examples for how to generate different types of markup, including JSON-LD, for most all of the types they define. See http://schema.org/Person for one example, or http://schema.org/docs/full.html for their complete type hierarchy.

The JSON-LD gem comes in handy when you want to generate this data from other sources (typically some RDF format), or interpret data you've received. You can experiment with this at http://json-ld.org/playground.

You can also include your JSON-LD in HTML using a script tag with type="application/ld+json" as your example does. If you want to see how your data looks, you can test it either on Google structured-data testing tool, or on http://linter.structured-data.org/

How to freeze gems in a Ruby application?

You could use them independently of the rubygems infrastructure by first unpacking each gem into vendor/gems (or whatever path within your project):

cd yourapp
mkdir -p vendor/gems
cd vendor/gems
gem unpack gem1
gem unpack gem2
[etc.]

... and then adding all the frozen gems' lib directories into your load path:

$:.unshift(*Dir[File.dirname(__FILE__) + "/vendor/gems/**/lib"])

How do I freeze gems into a Rails 3 application?

I haven't had to do this yet, but I believe it's all handled by bundler.

When you create a new rails3 app, the rails dependencies are put into your Gemfile. You can run bundle install to install them. By default, they are installed into your BUNDLE_PATH.

If you want to install them within your app, you can specify where: bundle install vendor/gems.

How do I fix this error? config.gem: Unpacked gem authlogic-2.1.3 in vendor/gems has no specification file

I am not sure why it is broken in Authlogic, but I had to generate it myself.

Try this in your Rails project:

$prompt> cd vendor/gems/authlogic-2.1.3

$prompt> gem specification authlogic > .specification

Removed unpacked gems folders, now gettings errors

Ah, figured out a way around this problem:

I just created a new rails app, gave it shoulda as a gem dependency, then unpacked the gems and froze rails. Then I just copied the folders vendor/gems/ and vendor/rails/ over to my actual app, and everything works. Now I just have to use actual rails commands this time (like rake rails:unfreeze).

---

Related Topics