[Rubygems-developers] What plans now?

Chad Fowler chad at chadfowler.com
Sun May 16 10:03:32 EDT 2004

On 16/5/2004, at 7:25 AM, Gavin Sinclair wrote:

> Hi folks,
> What plans do we have for RubyGems now?  There seem to have been a few
> fixes since 0.3.0.  Time for a 0.3.1 release?

Wouldn't hurt.  The changes have been fairly minor, but it's always 
good to have people testing a version that's as recent as possible.

> What about beyond that?  I'd like to bring about some unification in
> the code base.  At the moment, gem objects don't have primacy.  The
> code is more about processes than about data.  I'd like to see some
> sort of class hierachy that gives you access to all sorts of gems:
> local and remote, installed and uninstalled.

I'm all for making the API more convenient and powerful, but I don't 
think I'm very close to being sold on doing it via Gem inheritance.  In 
this context, I'd say that a gem is a gem.  You can store it locally or 
remotely and you can install and uninstall it, but it's still a gem.  
These really *are* processes, right?

I could see how this could be an argument for getting a little more 
uniform about how we represent a "repository".  Maybe that's the noun 
you're looking for?  Right now we call that 'cache', which I know you 
hate. :)  Should we look at doing local and remote ones in an OO way?  
I'm not sure.

> From that point of view,
> we should have the basis for a very powerful system.  Part and parcel
> of this would be caching information about what gems are available
> remotely, making remote lists and searches faster.

Caching would be nice.

> Also, the time might be right for an enhancement to the gemspec along
> these lines:
>   spec.add_files do |fs|
>     fs.bin << FileList['bin/*.rb']
>     fs.lib << FileList['lib/**/*.rb']
>     fs.doc << FileList['README', 'TODO', 'ChangeLog']
>   end
> I'm using the Rake concept of FileList for two reasons:
>  * it's easy
>  * it automatically excludes CVS directories and backups
>    - that's probably a good thing for RubyGems users, right?

Makes sense.  It would be nice to be able to pass it an array of 
strings *or* a FileList.

> However, the real benefits of this are:
>  * knowing which files are documentation means we can enhance the gem
>    browser to see *all* documentation files, not just the generated
>    RDoc ones
>  * it's perhaps more natural than the current 'require_paths' and
>    'bindir' specifications?

I'm not sure we can leave out require_paths and bindir just based on 
this, but if you can and can make it work cleanly, I'm all for it.

> I've brought this concept up before (long ago) and been told to go
> ahead.  I did so, but it took me ages and I ended up throwing it away
> rather than try to integrate it.  What do you guys think about it now?

I still like it.  The .doc thing would allow us to create a doc bundle 
generator or to publish documentation to the web in some easy/standard 


More information about the Rubygems-developers mailing list