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