[LazySpecification] Uniq dependencies in lockfile representation

[segiddins]

Closes #3522, but I'm not convinced this is the right thing to do.

[indirect]

I mean, it's illegal to have multiple dependencies on the same gem now, but we'll still have to handle this one version of treetop for a long time. Not sure if there is a "right thing" beyond deleting the dupes :P

[indirect]

Also it's failing on Ruby 1.8, could you take a look?

[arthurnn]

can we fix this server side? so our dependencies api return the right thing?

[TimMoore]

It's a problem with the gemspec in an older version of the gem, so there's not really a way to fix it on the server.

[arthurnn]

https://rubygems.org/gems/treetop/versions/1.4.10 . We could ask the author to yank that version..

[segiddins]

@arthurnn we shouldn't make them yank the version just because the tooling on our end is faulty, especially when it's in our power to correct the 'issue'

[indirect]

Yanking that version doesn’t fix the problem. The gem file, and the gemspec inside it, are on thousands of servers and machines all over the world. That version is also locked in thousands of Gemfile.locks. Yanking would just break bundle install for all those people, and the problem would still happen every time they run bundle install on a machine that already has it installed.

On Mar 27, 2015, at 2:49 PM, Arthur Nogueira Neves notifications@github.com wrote:

https://rubygems.org/gems/treetop/versions/1.4.10 https://rubygems.org/gems/treetop/versions/1.4.10 . We could ask the author to yank that version..

—
Reply to this email directly or view it on GitHub #3524 (comment).

[segiddins]

These spec failures on 1.8 are all totally unrelated

[indirect]

I fixed the specs! (Also, @segiddins fixed the specs.) Merging.