[Rubygems-developers] gem lock
jbarnette at gmail.com
Thu Sep 30 01:02:07 EDT 2010
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.
> I'd love to see a roadmap and feature list laid down for 1.4 as soon as
> possible. Target it for RubyConf week.
> On Wed, Sep 29, 2010 at 11:26 PM, James Tucker <jftucker at gmail.com> wrote:
>> On 30 Sep 2010, at 00:12, Ryan Davis wrote:
>>> On Sep 29, 2010, at 19:57 , James Tucker wrote:
>>>> On 29 Sep 2010, at 22:00, Ryan Davis wrote:
>>>>> I've been talking to Eric about the possibility of merging Isolate into
>> rubygems and he's agreed that it is a good idea.
>>> for the same reason that `gem lock` exists, only it works and people use
>> Not why does Isolate exist, I mean why merge this into RubyGems?
>> Isolate has the same bugs already described earlier in this thread. I know
>> it's "simple" by comparison to other offerings that have a feature or two in
>> common, I get that, but that is not a reason for RubyGems to merge it in,
>> especially if it doesn't actually solve bugs already described.
>> Rubygems-developers mailing list
>> Rubygems-developers at rubyforge.org
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
More information about the Rubygems-developers