your solution to developing gems in rails

[Tim Uckun]

One pain point I have is developing gems for rails.

Ideally I would have this in my gemfile

group :production do
gem 'blah' , :git => 'git:...'
end

group :development do
hostname :my_host_name do
gem "blah", :path => 'blah'
end
end

This way I could work on the gem and my collaborators could also work
on the gem and the deployment would come out of github. Of course
bundler doesn't work like this so I have tried several things to make
this work but I find none of them fully satisfactory. I am curious to
see what solutions if any you guys have come up with.

[Fred Wu]

We used something like this:

https://github.com/stonean/slim/blob/master/Gemfile

[Warren Seen]

+1 for this approach, have used it in the past too. Setting an env var is a dead simple approach and doesn't force your whole team into the same working directory setup.

On 13/09/2011, at 8:49 AM, Fred Wu wrote:

We used something like this:

https://github.com/stonean/slim/blob/master/Gemfile

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/JpQF1R5DJskJ.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

[Simon Russell]

The only problem there is that your Gemfile.lock will be changing
depending on who's making it, but that can be managed.

[Warren Seen]

Yes, that is true, there is an extra step involved in re-running bundle whenever Gemfile.lock gets updated. Not a huge deal in practice mind you, since you'll know pretty quickly if you've forgotten that step. :)

[Pat Allan]

Environment variables in a Gemfile feel like a code smell to me - if it's a gem you're all working on, then I'd just push all my changes to the gem into a certain branch on Github.

Of course, using :path while working on it is helpful - I'd just change the Gemfile but not check it in while working on it. But yeah, that's not ideal either.

--
Pat

[Warren Seen]

In some circumstances, I'd agree, but we were working on both an engine, and a couple of sites that used the engine - this was the simplest workflow we could come up with. It seems excessive to commit changes, push to github, then use bundler to pull those same changes down to a different location on your machine as part of your day to day workflow.

Once the bulk of the work was done and the engine was reasonably complete though, I think the approach you're suggesting would have been fine. My contract ended before we got to that stage though, so I don't know how it ended up! :)

Cheers,

W.

[Ben Hoskings]

On 13/09/2011, at 8:45 AM, Tim Uckun wrote:

> One pain point I have is developing gems for rails.
>
> Ideally I would have this in my gemfile
>
> group :production do
> gem 'blah' , :git => 'git:...'
> end
>
> group :development do
> hostname :my_host_name do
> gem "blah", :path => 'blah'
> end
> end

This is probably a bad idea -- it's too easy for the version of the gem you develop against locally, and run the test suite against, to drift from what's running in production.

using `gem 'blah', path: '~/code/...'` is really useful for quick testing, but I don't think it should be used for your general dev setup.

The process of spec/code/commit/push on a gem is easy enough that using git paths and re-bundling isn't too much of an overhead, for most cases.

- Ben

[Tim Uckun]

My solution has been to check the gem as a submodule into vendor/engines

gem 'mygem', '0.0.0', :path => 'vendor/engines/mygem'

I do a git init submodule && git update submodule in the capfile for
deployment. This works OK for my use case but it also has it's painful
spots.

Bundler really ought to have a better solution for this. I like the
idea of a hostname based solution where each developer (and possibly
each server) could have a different set of gems from different
locations.