[Rubygems-developers] What plans now?
chad at chadfowler.com
Sun May 16 19:50:30 EDT 2004
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.
>> this context, I'd say that a gem is a gem. You can store it locally
>> 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 ) and wanting to see a good solid repository. What
> of objects do you think should go in a repository?
>  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)?
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']
>>> 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
>> 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
> I'm right with you.
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
More information about the Rubygems-developers