Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Rubygems 2.2.2 uselessly hits the dependency API when installing a local gem file #816

Open
indirect opened this Issue Feb 7, 2014 · 8 comments

Comments

Projects
None yet
6 participants
Owner

indirect commented Feb 7, 2014

The .gem file that I'm installing has the gemspec with the dependency information in it. The gem has no runtime dependencies. All 4 network requests are unnecessary to install the gem.

gem install pkg/bundler-1.5.3.gem --verbose
HEAD http://api.rubygems.org/api/v1/dependencies
302 Moved Temporarily
HEAD http://bundler.rubygems.org/api/v1/dependencies
200 OK
GET http://api.rubygems.org/api/v1/dependencies?gems=bundler
302 Moved Temporarily
GET http://bundler.rubygems.org/api/v1/dependencies?gems=bundler
200 OK
Owner

drbrain commented Feb 11, 2014

The first request is a probe for the dependency API since the default mode is --remote.

I'm unsure where the second one comes from so I will investigate.

@drbrain drbrain added this to the 2.3 milestone Feb 11, 2014

@ghost

ghost commented Feb 11, 2014

@drbrain is the default (--remote) not unnecessary when it is obvious the gem is being installed from disk, and has no dependencies?

Owner

indirect commented Feb 11, 2014

The default mode for installing local .gem files with no dependencies is --remote? That seems... less than optimal. Should I open a separate ticket for that?

On Tue, Feb 11, 2014 at 1:48 AM, Eric Hodel notifications@github.com
wrote:

The first request is a probe for the dependency API since the default mode is --remote.

I'm unsure where the second one comes from so I will investigate.

Reply to this email directly or view it on GitHub:
#816 (comment)

@drbrain drbrain modified the milestones: Future, 2.3 May 14, 2014

@drbrain drbrain added type - feature and removed type - bug labels May 14, 2014

Owner

drbrain commented May 14, 2014

The default mode for gem install is --both so remote requests will be made if you don't have all the dependencies locally.

These requests are not much different than the checks rubygems made before the new resolver was added, so I've bumped this past rubygems 2.3

Owner

indirect commented May 14, 2014

"if you don't have the dependencies" can't be true. the entire point of this ticket is that it was a local .gem file with zero dependencies.

On Wed, May 14, 2014 at 5:18 AM, Eric Hodel notifications@github.com
wrote:

The default mode for gem install is --both so remote requests will be made if you don't have all the dependencies locally.

These requests are not much different than the checks rubygems made before the new resolver was added, so I've bumped this past rubygems 2.3

Reply to this email directly or view it on GitHub:
#816 (comment)

Owner

drbrain commented May 14, 2014

Yep!

This can be improved, but it's no different than past RubyGems behavior so I don't find it critical for 2.3. I would like to get 2.3 out the door this month and I think changing his behavior myself will take too much time. (I can consult on a pull request for inclusion on 2.3, through)

Contributor

copiousfreetime commented Jan 31, 2016

To clarify this issue:

If the gem to be installed is local, and all the dependencies are currently satisfied then make it a local install? Or do we want to only do this if if the gem being installed has zero dependencies?

I think this could be merged with #108

@lynncyrin lynncyrin removed the accepted label Jun 9, 2016

@lynncyrin lynncyrin removed this from the Future milestone Jun 9, 2016

Member

sonalkr132 commented Aug 3, 2016 edited

As mentioned, two requests are originating from two different places:

installer_set should not ask remote_set to find_all dependencies of req if req has no dependencies. req is just a Gem::Resolver::DependencyRequest object, so it doesn't know about local spec(which would contain dependencies).

This can be solved if we don't prefetch when reqs is empty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment