[Rubygems-developers] What plans now?
gsinclair at soyabean.com.au
Sun May 16 11:36:48 EDT 2004
On Monday, May 17, 2004, 1:11:13 AM, Curt wrote:
> Chad Fowler wrote:
>> 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.
> I haven't looked at this in a few weeks, to maybe it has changed, but the
> main file that implements the command line interface mixes API with command
> interface. I remember wanting to separate these so that the command line
> process requires/uses the same API file my GUI browser would use,
No, nothing's changed :( That's definitely something we need to
address, but it may take a bit of sleeves-up dirty work. I'm happy to
do the dirty work, but I'd like some help from you on what the API
should look like.
It's important to remember that various events can happen inside the
API that different clients will handle differently. For example,
getting confirmation before installing a slew of dependencies. Your
client does something with dialog boxes; 'gem' uses STDOUT/STDIN. We
need to model that sort of interaction adequately.
More information about the Rubygems-developers