config.gem compatibility with vendor/gem git submodule workflow

This would definitely make sense if you use submodules and are bumping the version number frequently on your gem, which is something I've tried but gave up on due to the pain you describe.

I'm running into this issue, too. In particular, there are some gems I want to track the trunk of our own fork via a submodule.

The new code in 2.2RC can handle this, but the process is a little convoluted. You'll probably want to start by unpacking the regular (ie not forked) gem using rake gems:unpack. That will give you a correct .specification file. Next, move the .specification file someplace safe and remove the unpacked gem directory in vendor/gems. Finally, clone the git repo into vendor/gems/-, just like the system gem. Move the .specification file back, (add it to the repo?) and you should be in business.

A little bit complicated - I'll look into adding a rake task to do this directly. It should be easier now, as (most) gems on github have gemspecs in them...

Uggg that is kind of a pain... the other thing is this:

railties/lib/rails/gem_dependency.rb:28

unpacked_paths = Dir[File.join(self.class.unpacked_path, "#{@name}-#{@version || "*"}")]

That damn dash means that I have to put my custom/"fake" gems in 'haml-', etc.

I guess it could be:

unpacked_paths = Dir[File.join(self.class.unpacked_path, "#{@name}#{@version ? "-#{@version}" : "*"}")]

Or would that cause unforeseen problems?

I have a few gems that I've altered in small ways but don't really feel like making back into github gems; for example, I altered haml to include a IE6 CSS hack so that CSS selectors like input[type=submit] work.

The change above isn't relevant - the code was totally rewritten for 2.2. The simplest resolution for your problem is to check the code out into version-named directories (ie haml into 'vendor/gems/haml-0.1.2', for example) and then run 'rake gems:refresh_specs'. It should put a workable spec in that directory.

Note that this advice only applies to 2.2; on 2.1 you're pretty much SOL.

On a totally unrelated note, you might want to check out IE7.js and friends for make IE6 behave properly.

Hi Matt,

Thank you for all the speedy responses!

So, ok I tried messing around with the version-named directories, but I just decided to create a new directory in vendor/ called faux_gems/ to use in conjunction with the old-school solution:

config.load_paths += Dir["#{RAILS_ROOT}/vendor/faux_gems/**"].map do |dir|
  File.directory?(lib = "#{dir}/lib") ? lib : dir
end

Not ideal, but I'm not thrilled with the whole gem system anyway. Plugins are much nicer for quick hacking since you don't have to re-release everything. If I need a 1 line fix in a gem it seems like overkill to have to deal with version numbers, etc. Am I missing something here?

Anyway, for everything else that I haven't touched I'm using config.gem and it's working great. Is it typical to include rake gems:install in cap deploy?

And thanks for that IE js tip! I'll check it out.

Dear Aaron,

I've encountered the same problem as you and opted to leave the Rails code the same and name my submodule gems 'example-'

This way rails will load them but you might loose config.gem functionality. But in my opinion the git submodule's in the vendor directory already provide that functionality.

Best regards, Sytse

We've taken a similar approach to Aaron (called our dir vendor/garnets) to avoid a spattering of warnings at startup.

Hi Luke,

Just for clarity, by renaming the gems to 'example-' you can still use the config.gem dependency and don't get a warning when starting the server. The only thing you might not be able to do is run the rake tasks for gems.

Best regards, Sytse

So, it feels like there should be some way to have submodule'd gems and regular versioned gems coexist in vendor/gems. Could some sort of convention be adopted to allow certain directories in vendor/gems be ignored by the rake:gems tasks...maybe for a certain directory name? Maybe some sort of .gemrails_ignore file inside the gem directory?

Ignoring the directories isn't really enough; if you have a submoduled gem that another gem depends on, things have to be set up correctly to avoid loading files from the system gems.

I'm hoping to get a patch together soon that will read the gemspec files from the git repo directly, or from the system gems if there isn't one in the repo.