Hi Guyren, The maintenance cost of organizing dependencies between gems is real and can severely impact workflow (same can also be said for multiple apps/services). I've seen teams both small (1-2) and large (30+ devs) struggle with this. This is especially true for gems that are in active development as you're encountering because of the Gemfile/gemspec dance you are describing.
If there are strict dependencies between gems, you may want to just group them in a single gem/fewer gems, e.g. A utilities gem. That significantly reduces dependency maintenance overhead while still allowing you to reuse the code across multiple projects. The only reason I can come up with, that might prohibit this, is if you need specific combinations of versions of the gems i.e. A needs B' and B needs A', though if that is the case, I would look closely at whether those 'needs' can be eliminated. If you really want to split out a piece, for whatever reason, i'd wait for it to be code that is unlikely to change in the future so you don't have to do the dance with that particular gem. A nice example of a single gem setup is the rack gem which has quite a few core libs grouped under the the rack namespace. Then in your app/project if you want to require certain pieces you can 'require "utilities/foo"' or use autoloading. Both rack and thin are very well organized with autoloading as their approach: https://github.com/rack/rack/blob/master/lib/rack.rb https://github.com/macournoyer/thin/blob/master/lib/thin.rb Is there any reason you can't group them into fewer gems? - Dave On Saturday, June 4, 2016, Guyren Howe <[email protected]> wrote: > I'm developing a fairly large collection of what you might call > micro-gems. I've about a dozen now and more to come. > > There doesn't seem to be a way to manage loading these things while I'm in > development that isn't remarkably painful. I can't specify their > interdependencies in the gemspecs, because I can't specify a path in a > gemspec. The only way I can find to make it work is to include the > dependencies in the Gemfiles. But if gems A and B need gem C, I can't just > put C in A's gemfile and expect it to be visible from B. It seems I have to > laboriously provide explicit gem dependency inclusions in every gem. > > This is turning into a maintenance nightmare, and will be worse when I > want to release all this because I've got to go through and empty out all > the dependencies in all the Gemfiles first. > > What am I missing, or is this in fact just something I have to accept? > > -- > -- > SD Ruby mailing list > [email protected] <javascript:;> > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google Groups > "SD Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:;>. > For more options, visit https://groups.google.com/d/optout. > -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
