[Rubygems-developers] What plans now?
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
>> 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 ) and wanting to see a good solid repository. What kind
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)?
>> 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).
>> 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
I'm right with you.
More information about the Rubygems-developers