[Rubygems-developers] What is right and wrong with dependencies definitions?

Eric Hodel drbrain at segment7.net
Sat Nov 10 15:55:36 EST 2007


On Nov 10, 2007, at 11:26 , Chad Woolley wrote:
> On 11/9/07, Eric Hodel <drbrain at segment7.net> wrote:
>> On Nov 9, 2007, at 16:08 , Chad Woolley wrote:
>>> I don't want to force everyone who uses it
>>> to install the dozen-plus build- and deploy- and test-time
>>> dependencies I have.  This
>>> would freak some people out when they installed it and make them not
>>> want to use the gem.
>>
>> I've installed things that easily have more dependencies than that.
>> I think lots of dependencies with a small gem is a good thing, since
>> it means the author is probably being a good citizen.
>
> Hmm.  Interesting, and still a matter of opinion :)

This is for C programs and libraries, primarily.

> Why does that make you a good citizen?  Because you are reusing code?
> Or because you are being explicit about your dependencies?

Code reuse.

> In my experience, I've found that LESS actual dependencies is a good
> thing, because that's less opportunity for me to get in dependency
> hell (incompatibilities that I don't understand or can't resolve).
> For example, I started using needle on my project, but then rolled my
> own DI so I wouldn't have that dependency, and it was simpler and
> better-tested.  Granted, this is probably a somewhat-unnecessary
> holdover from my Java days, because it's much easier to deal with this
> in ruby by monkey-patching.

I think the majority of the problem is that Ruby's libraries haven't  
matured enough yet.

I'll use an external library until it becomes too complicated to  
maintain, then I'll fix it, and if I can't, I'll replace it.  Without  
mature libraries, we all end up at step three too often.  Sometimes  
often enough that we skip right to step three.

>>> Plus, it's very likely (especially in the case
>>> of Rspec) that one of my dependency versions conflicts with  
>>> something
>>> else on their system, and unless they have their rspec version  
>>> locked
>>> down everywhere (unlikely) the mere installation of my gem will  
>>> screw
>>> them if it auto-installs a newer version of rspec that's  
>>> incompatible
>>> with their old specs.
>>
>> I believe that RubyGems has the ability to handle this gracefully
>> with sane versioning schemes combined with the existing requirement
>> specifiers (including '~>'), and that this is primarily a gem author
>> education problem.  When severity of changes doesn't match changes in
>> version numbers, everybody is going to suffer.
>
> Sorry, I've gotta disagree here (and I'm_definitely not bikeshedding
> here, because my and my shop, which includes an rspec committer, are
> early rspec adopters, and we have been along for the whole ride).
> Even if rspec had sane versiong schemes (which they really don't), it
> wouldn't solve the problem I mentioned:
>
> 1. I force a newer version of rspec to be installed
> 2. User installs my gem
> 3. The newer version of rspec breaks all my user's tests
> 4. User gets pissed because my gem "broke" them.  Yes, it's their
> fault for not locking down their rspec version, but the user is always
> right!  Plus, they have a somewhat valid reason to be pissed, because
> the newer version of rspec is completely unnecessary for my gem to
> work correctly for them.

Customers are always right, but I doubt these users paid you.  IMO,  
tough for them (for now).

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars




More information about the Rubygems-developers mailing list