[Rubygems-developers] What plans now?

[Chad Fowler]

On 16/5/2004, at 12:06 PM, Gavin Sinclair wrote:

> On Monday, May 17, 2004, 12:03:32 AM, Chad wrote:
>
>
>> On 16/5/2004, at 7:25 AM, Gavin Sinclair wrote:
>
>>> 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?
>

Gems :)

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

RemoteCache?

>>> 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)?
>

I would think so.  Transparently.

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

Hmm...we could always just steal the code.  If we're going to have a 
Rake dependency, it would be nice to distribute a Rake gem along with 
RubyGems and just auto-install it ala sources.

>>> 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.
>
> Cheers,
> Gavin
>
>
>
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers