[Rubygems-developers] What plans now?

Gavin Sinclair gsinclair at soyabean.com.au
Sun May 16 12:06:47 EDT 2004

On Monday, May 17, 2004, 12:03:32 AM, Chad wrote:

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

I thought there were one or two significant changes, but I can't
remember what.

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

Well, you're right about me not liking 'cache' (at least the current
way it's used [1]) and wanting to see a good solid repository.  What kind
of objects do you think should go in a repository?

[1] Currently, a Cache represents the gems you have installed, and has
nothing to do with remote operations.

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

A repository should handle that, right (at least indirectly)?

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

I suppose the only way a person can use a FileList in a gem is to
require 'rake', right?  No chance of RubyGems supporting it directly?
(It's probably a bad idea, but it's an idea I had long ago.)  I'll
certainly look at accepting either/or, anyway.  Rake has an
experimental change at the moment which might make FileLists behave in
a peculiar way (so they evaluate lazily).

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

Yeah, could be difficult, but worth a try.

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

I'm right with you.


More information about the Rubygems-developers mailing list