| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
WIP: add command to check dynamic library linkage
This new command, linkage, checks for broken dynamic library links in C extensions.
I'd heard there was some interest in adding this functionality, so I thought I'd submit a preliminary PR for discussion. In my experience, broken dylib linkage is a common issue with C extensions, so I think having a good way to diagnose it would be valuable.
This command scans all of the specifications in the bundle for .bundle files in C extensions. If any of the dynamic libraries linked against no longer exist, bundler will report a message to the console and exit non-0.
TODOs:
* Add support for non-Darwin OSs
* Improve tests
A few questions:
* Is there a good way to mock functionality in the tests? Doing it in the standard rspec way isn't working since `bundle :command` runs in a subprocess. I'd like to be able to stub out stuff that actually checks dylibs and the like.
* Is making this a new command the right approach? I assumed this wouldn't be ideal to include in, say, `check` because it would slow it down.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This will eventually support other tests, so the dylib test needs to be
able to to meaningfully return an empty result
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This new command, doctor, checks for common problems.
Currently, it looks for broken dynamic library links in C
extensions.
It scans all of the specifications in the bundle for .bundle files in C
extensions. If any of the dynamic libraries linked against no longer
exist, bundler will report a message to the console.
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
Remove Bundler::Environment
Pretty straightforward refactoring
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Remove expect_err from the specs & print all output on a spec failure
This now also appends all executed commands to failed examples, meaning we don't have to scroll up to see the output from a failing test:
```
Failures:
1) The library itself does not contain any warnings
Failure/Error:
sys_exec!("ruby -w -I.") do |input, _, _|
lib_files.each do |f|
input.puts "require '#{f}'"
end
input.puts "abort 'fdsfds'"
end
RuntimeError:
Invoking sys_exec!("ruby -w -I.") failed:
fdsfds
Commands:
$ ruby -w -I.
fdsfds
# $? => 1
# ./spec/quality_spec.rb:205:in `block (3 levels) in <top (required)>'
# ./spec/quality_spec.rb:196:in `chdir'
# ./spec/quality_spec.rb:196:in `block (2 levels) in <top (required)>'
```
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | | |
[Graph] Remove monkey-patching of Gem::Dependency
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Hopefully this will be consistent between machines
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/ |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Display message showing locked Bundler version is being installed
This is for #4753.
[This](https://github.com/bundler/bundler/issues/4753#issuecomment-233786976) always showed the installing message whether the locked Bundler version was installed or not, so I moved the line into `lib/bundler/vendor/postit/lib/postit/installer.rb`.
I've also added the appropriate specs for this.
@RochesterinNYC @segiddins @indirect
|
| | |
| |
| |
| | |
Remove bang from `gsub`
|
| | |
| |
| |
| | |
Fix rubocop offense
|
| | |
| |
| |
| | |
Use `warn`
|
| | |
| |
| |
| | |
Move message into non-vendor file
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Add message filter to generate better search URL
Fixes #4771
/c @RochesterinNYC @segiddins
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | | |
Bundler version warning should not print when versions match
Closes #4752
@RochesterinNYC @indirect
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=indirect
Add an open_timeout to the fetcher connection
Overview
--------
When ruby makes an HTTP connection with the `Net::HTTP` library, by default, it has no timeout to setup that connection.
```ruby
# excerpts from net/http stdlib
def initialize(address, port = nil)
@address = address
@port = (port || HTTP.default_port)
@local_host = nil
@local_port = nil
@curr_http_version = HTTPVersion
@keep_alive_timeout = 2
@last_communicated = nil
@close_on_empty_response = false
@socket = nil
@started = false
@open_timeout = nil
@read_timeout = 60
# ...
end
def connect
if proxy? then
conn_address = proxy_address
conn_port = proxy_port
else
conn_address = address
conn_port = port
end
D "opening connection to #{conn_address}:#{conn_port}..."
s = Timeout.timeout(@open_timeout, Net::OpenTimeout) {
TCPSocket.open(conn_address, conn_port, @local_host, @local_port)
}
# ...
if use_ssl?
# ...
Timeout.timeout(@open_timeout, Net::OpenTimeout) { s.connect }
end
end
```
It can be set by changing the `open_timeout` variable on the connection object, but beyond that, it will attempt a connection unless an error is returned from the server. The Net::HTTP::Persistent library included with bundler also maintains this same interface when dealing with threads, and eventually passes that same value down to the Net::HTTP lib.
It is possible to get into a state where bundler is currently attempting to establish a connection indefinitely to rubygems because this timeout is not in place. Using the `Fetcher.api_timeout`, which is just pulled from the `Bundler.settings[:timeout]` value (defaults to 10 sec), we can also provide an `open_timeout` value and prevent this. In most cases, and HTTP connection should be established in less than a second (if not, there is probably a bigger problem), and most uses of the Fecther's connection are also wrapped in a Bundler::Retry, so if it fails do to a network hiccup, it will be attempted again.
I was having this happen to me on a pretty consistent basis, and while it is probably more likely my ISP or something fishy with my home network, this seems like a relatively harmless fix. In the code excerpts above from the STDLIB `net/http`, I would consistently have one or two Threads from the `CompactIndex` stall on the `s.connect`, which was while it was attempting to make an https connection.
Unfortunately, I can't think of a good way to test or reproduce this consistently (and of course, now I can't even reproduce it locally at all), so this PR is more of posing a question of "Do we want to do this, and why or why not?"
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When ruby makes an HTTP connection with the Net::HTTP library, but
default, it has no timeout to setup that connection. It can be set by
changing the `open_timeout` variable on the connection object, but
beyond that, it will attempt a connection unless an error is returned
from the server. The Net::HTTP::Persistent library included with
bundler also maintains this same interface when dealing with threads,
and eventually passes that same value down to the Net::HTTP lib.
It is possible to get into a state where bundler is currently attempting
to establish a connection indefinitely to rubygems because this timeout
is not in place. Using the `Fetcher.api_timeout`, which is just pulled
from the `Bundler.settings[:timeout]` value (defaults to 10 sec), we can
also provide an `open_timeout` value and prevent this.
In most cases, and HTTP connection should be established in less than a
second (if not, there is probably a bigger problem), and most uses of
the Fecther's connection are also wrapped in a Bundler::Retry, so if it
fails do to a network hiccup, it will be attempted again.
|
