[Rubygems-developers] The 1.7 Plan

James Tucker jftucker at gmail.com
Sat Mar 5 18:53:51 EST 2011

On Mar 3, 2011, at 5: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.

Nice :-)

> + 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.

Want, so much. Use case: https://github.com/rack/rack/blob/rack-1.1/test/gemloader.rb

Hoe could do with something similar, and that would be well served by the above feature. (Note: the reason is that rack-master and rack-1.1 have different version dependencies)

> + 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).

Totally, I mentioned to evan the other day that I'd really like to strip this down as much as possible, and maybe even keep the minimum required details in a single marshalled file, in order to massively speed up boot times when loading gems. My spec.files patch made a 75% reduction in ram usage, but we can go a lot further, deserialization is expensive.

> + 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.

If time is available to do anything, do you want it in topic branches? is it safe to branch from master, or would you prefer them be based off the 1.6 branch?

More information about the Rubygems-developers mailing list