[Rubygems-developers] Design notes for RubyGems 2
chad at chadfowler.com
Tue Jun 8 19:17:39 EDT 2004
On 8/6/2004, at 2:15 PM, Curt Hibbs wrote:
> Chad Fowler wrote:
>> On Wed, 9 Jun 2004, Gavin Sinclair wrote:
>> # The reality is that RubyGems is pretty simple. I want an interface
>> # the main thing in the system - the collection of gems - that is also
>> # simple. Tell it want you want and you get it. Obviously that needs
>> # to be codified somewhat. But the current system is more like
>> # low-level scratching than high-level ease.
>> Agreed on the simplicity comment. To me, the interface you're talking
>> about looks something like this:
>> Gem::Cache.from_installed_gems.each do |gemspec|
>> There might be some things lacking, but I'd like to see them built
>> on a concrete need for them.
> Why not:
> repo = new Repository(LOCALHOST)
> repo.each_installed_gem do |gem|
It looks fine, but it also looks a lot like what already exists (with
the difference being the name of the class). As I made a failed
attempt to travel to California today, I thought about the need for
"Repository" and convinced myself that "Repository" could be pretty
simply factored out of the Installer and RemoteInstaller code,
potentially reducing some duplication.
> (Of course, the first two lines could be written as one line.)
> A GUI gems browser is going to want to have a navigation tree control
> can enumerate known repositories (local and remote) and the gems
> within each
> repository. Once enumerated and displayed, if the user selects an item
> the GUI tree, it needs to know what that corresponds to.
> The GUI browser could maintain its map of associations between
> and data that identifies the gem and/or repository. In the absence of
> and Repository objects from RubyGems, I would define such objects
I think if you were to start writing the GUI browser, you would realize
that a "Gem" is not really necessary or advantageous to do what you
want, given the existence of "Specification". You are probably right
that some other way of dealing with local and remote collections of
gems would be helpful, purely from the perspective of being able to
deal with them polymorphically, though I think it would be interesting
for you to try it with the current code and see what you run into. My
hunch is that you will have a fairly easy time of it without any major
changes to the existing libs.
> But that seems silly when those objects should properly be part of
> After all, a GUI browser isn't the only thing that leverage off the
> to manipulate gems and repositories as objects, RubyGems can leverage
> as well.
> With objects, we can maintain arrays, hashes, or whatever of gems
> (heck, we can make use of the full power of Ruby! :). As I said
> this would not only make life better for the clients of RubyGem
> but also for RubyGems internals. Caches, for example, would be simple
> construct as gem and repository objects could be easily serialized to
> XML or
> YAML, or even use a Madeline db.
This all sounds good. I don't see how it's not possible with what
we've already got (or perhaps incremental improvements to what we've
got). I'd like to see some specific examples from someone who is
running into problems and/or difficulties.
BTW, This sounds like a lot of disagreement, but disagreement is good.
I'm sure something better will come out of this discussion and the
actions taken as a result of this discussion.
More information about the Rubygems-developers