Http driver config #273
Http driver config #273
Conversation
2 similar comments
1 similar comment
3 similar comments
2 similar comments
4 similar comments
6 similar comments
8 similar comments
There was a problem hiding this comment.
I feel like I'm not following the conversation very well because of all of the noise from coveralls, so sorry if I'm repeating things unnecessarily.... I also feel like I haven't been engaging well enough in this PR until now because of time restrictions, so please forgive me if things are a bit confusing.
But one general point: If you don't care about the old session code, I don't either. I'm perfectly happy to only implement this change in the new HTTP adaptor which would simplify things
| @@ -16,7 +17,8 @@ def initialize(url, options = {}) | |||
| end | |||
|
|
|||
| def connect | |||
| @requestor = Requestor.new(@url, USER_AGENT_STRING, self.class.method(:instrument_request)) | |||
| @requestor = Requestor.new(@url, USER_AGENT_STRING, self.class.method(:instrument_request), | |||
| @options[:faraday_options] || @options['faraday_options'] || {}) | |||
There was a problem hiding this comment.
I think that you should just be able to do @options['faraday_options'] || {}, right?
There was a problem hiding this comment.
Not unless I stringify_keys! since coders will likely use :faraday_options but when config'ed via neo4j.yml (ie in Rails), the keys are strings. There is an explicit test for this.
| c.response :multi_json, symbolize_keys: true, content_type: 'application/json' | ||
| c.use Faraday::Adapter::NetHttpPersistent | ||
|
|
||
| conn = Faraday.new(url) do |c| | ||
| # c.response :logger, ::Logger.new(STDOUT), bodies: true |
There was a problem hiding this comment.
Just verifying, if you leave these lines in, are they no longer defaults but rather they override the options?
There was a problem hiding this comment.
That is my understanding - all the middleware that gets called during initialization gets mounted in Faraday and these would then always get mounted no matter if people wanted them or not, and there would be no way to get rid of them.
| end | ||
|
|
||
| def extract_basic_auth(url, params) | ||
| return unless url && URI(url).userinfo |
There was a problem hiding this comment.
Not a huge deal, but you could perhaps create a uri object at the start and use it in all of the places you're using URI(url)
| def verify_faraday_options(faraday_options = {}, defaults = {}) | ||
| faraday_options.symbolize_keys!.reverse_merge!(defaults) | ||
| faraday_options[:adapter] ||= :net_http_persistent | ||
| require 'typhoeus/adapters/faraday' if faraday_options[:adapter].to_sym == :typhoeus |
There was a problem hiding this comment.
Shouldn't the user require the gem paths that they need depending on the adaptor that they are using? That way we wouldn't need to include the various gems in our Gemfile
There was a problem hiding this comment.
Yes, that is true... I was just bitten by typhoeus/typhoeus#226 (comment) which was a little hard to track down the solution, so I figured it would be a little easier to just handle that for them instead (plus it is only needed here, not in their project generally). Happy to take it out if you'd rather doc it / force folks to figure it out, but it seems like an easy win that doesn't really cost much here.
in the Gemfile I only include the adapter gems in :test (and not in the .gemspec) so tests here will fail if there's any issues vs letting people hit them when using whatever gems and fail and then report issues.
I can imagine if there is any issues with the adapter gem(s), it requires a little work to maintain the tests, but again, it seems like an easy thing we can stay on top of here vs just letting people get bitten and have to figure it out themselves..?
I'm of the understanding that only the .gemspec gems are exposed outwards, and so having gem in the Gemfile doesn't really impact anyone else - is that correct?
| faraday.send key, value | ||
| end | ||
| end | ||
| end |
There was a problem hiding this comment.
I'm not really sure I get why all of this is necessary. Doesn't the second argument of Faraday.new take a hash of options which is an alternative to sending methods to the faraday object in the block syntax? Maybe that's where we're misunderstanding...
There was a problem hiding this comment.
I didn't look too hard, but I took these comments to mean no since I don't see anything mentioning :response as a key, for instance. But yeah, if that's true that makes life much easier - I'll give it a try
8 similar comments
Fixes #272
This pull introduces/changes:
Pings:
@cheerfulstoic
@subvertallchris