[Rubygems-developers] gem lock
jftucker at gmail.com
Thu Sep 30 07:48:37 EDT 2010
On 30 Sep 2010, at 02:02, John Barnette wrote:
> On Sep 29, 2010, at 8:29 PM, Nick Quaranto wrote:
>> This conversation is about to take a horrible turn and I'd rather it not go
>> that way. Let's just deprecate the command and recommend using Bundler.
>> There's more important issues to solve with the rubygems client, such as
>> mirroring, the progress bar, and performance enhancements if at all
>> possible. Oh yeah, and what happened to gem metadata?
> I'd like to see `gem lock` deprecated and then removed. It's simply not good code. I'd prefer not to add any sandbox management (Isolate or anything else) features to RubyGems without solving the full-graph dependency resolution problem in a non-hacky way, which will require quite a bit of work on the way gem sources work, as well as potential changes/additions to source servers. This feels like a 2.0 kinda thing.
Thank you, both of you, these are my sentiments also.
Nick, I started up the Wiki again to start documenting some of the things I have planned to sort out platform integration issues and performance issues that are keeping gem_prelude alive (including plugin architecture). I'm hoping to be at Rubyconf this year as well, so it'd be nice if as you suggest we could maybe nail a large portion of these issues around that time. I'm really hoping I can get back to some of these issues soon, but I really don't have many chunks of focus time available right now. There are also important integration issues with the ruby-core stdlib gems discussion which tie into both the plugins and the platform integration discussions in important ways, and some of these things can be seen in my ruby-core posts on the topic. The concerns of system level packagers (and no, I am not just talking about Debian) are genuinely important, and if we don't address them there will be yet more hacks coming as a consequence. Furthermore, as someone seems to have once again picked up on Gem.datadir (which involves using the Gem library API), if this is re-popularised, some of the current hacks around these issues (such as gem2rpm) will become less appropriate in future. There's more research to be done in this area, and I'm happy for anyone who wants to, to come in and help. What I don't want to see though, is for someone to come in and create a load of patches that are unique to their platform, break backward compatibility, oversimplify the myriad of issues, or based on insufficient understanding of the problem domain (as per existing tickets that also contain important factors / information on this topic).
More information about the Rubygems-developers