Thanks much for the detailed replies to these issues (and especially if
some of the mentioned changes get made).
I'll see if I can provide a more detailed report on item #2 that I
mentioned.
- Tom
Jim Weirich wrote:
On 4/19/07, Thomas Palmer <[EMAIL PROTECTED]> wrote:
1. "gem install" doesn't default to the current platform (in my tests),
so people are forced to choose instead of letting install just work.
yes, but this is easily solvable ... its on the todo list for the gems
team. This issue will just push it to the front of the list.
2. I can't install and have active in the same local repo multiple
platforms of the same gem (i.e., different ones active for different
platforms).
Really? I think the repository structure should support this. We
might need some extra logic in the activate code to make sure we get
the right platform.
3. People getting confused when saying "Hey, this library doesn't work
according to docs!" and mistaking the responsible party. Maybe that can
be somewhat mitigated by clarifying in the author and other fields of
the platform-specific gem.
Yes, I don't know what to do about that. I think that if you were to
offer a java based version of any current gem, you would want to work
with the original author anyways ...to coordinate releases and keep
compatibility, etc. Under today's RubyForge structure, you would have
to publish the gem from the same RubyForge project, but that doesn't
mean you have to share the same SVN repository.
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
