[Rubygems-developers] The 1.7 Plan

Erik Hollensbe erik at hollensbe.org
Thu Mar 3 23:10:06 EST 2011


On Mar 3, 2011, at 8:26 PM, Ryan Davis wrote:

> Working on the installer and Gem.activate on 1.6 showed how crufty and painful Gem, Specification and Dependency were. 1.7 is going to focus almost entirely on refactoring the API into something useful. Specifically:
> 
> + GemPathSearcher needs to die. God I hate it. 100% of it is bad design and equivalent functionality should be built into specifications themselves.
> + The relationship between Specification and Dependency needs to be made more usable. In particular, going to source_index every time you need something is an abomination. Specification should be able to respond with all specs that match it's dependencies.
> + Installer code and activation code needs a refactoring. The fact that I had to do _nearly_ the same thing twice was proof of that.
> + Gem.activate should be moved to Specification#activate.
> + Gem.source_index should be hidden as an implementation detail (or removed) and proper public counterparts should be added (eg. Specification.all/active/find/named).
> + Lots more Gem class methods should be moved to where their responsibilities properly belong. There is so many LoD violations that it isn't funny.
> 
> I'm sure there is a lot more. That's just off the top of my head.
> 
> IMPORTANT: This release is going to be a code contraction month. Feature additions / enhancements should NOT go in master and should NOT be released in 1.7. We can add toys in 1.8.

Ryan,

I have some change proposals which will probably impact this rather significantly that I've been toying around with, e.g.:

https://gist.github.com/22fa600b8c98bdf8c785

It seems like implementing this would cover a lot of similar ground in spots. Is there a chance we can talk about how this fits in (or if it does at all) at some point? I was going to be drumming up a patch this weekend to integrate it for your guys' review, per a conversation with Eric and Evan.

-Erik


More information about the Rubygems-developers mailing list