Smarter initialization of default configuration

[tjohnell-handy]

Hello,

I ran into an interesting situation where I planned to use the default ENV var REDIS_URL to configure Redis and therefore did not explicitly set Split.redis on initialization of my Rails app. We use Figaro (https://github.com/laserlemon/figaro) to manage ENV variables, and I believe what's happening is Split is being loaded prior to any configuration/initialization of the Rails app (https://github.com/splitrb/split/blob/master/lib/split.rb#L69).

Split configuration, however, could be a little smarter. For instance, if it were to check for the existence of Railtie and conclude it's present, it could hook the initial configuration into the before_initialize callback. That would allow for gems like Figaro and dotenv to properly load relevant ENV variables allowing this gem to be more plug-and-play.

Just a recommendation. I wouldn't mind helping in my free time to submit a PR if you're interested.

Best,
Tom Johnell

[andrew]

@tjohnell-handy a PR to improve that would be very welcome 👍

[lcmen]

@tjohnell-handy you can simply solve it by assigning Redis.new to redis option in configure block:

Split.configure do |config|
  config.redis = Redis.new
end

[husteadrobert]

Is anyone still working on this issue? I'd be happy to submit a pull request with what I think fixes the issue, based on the comment from @tjohnell-handy . (This is my first attempt at contribution, so I already created the code before reading in the Code of Conduct it's better to ask if anyone is still working on it first).

Writing specs for the code is a little more difficult though, as I'm unsure how to test the issue without adding a bunch of dependencies into the specs, or if it's really even needed since the specs check to see if there are ENV variables already.

[andrehjr]

Hi @husteadrobert, awesome!

I don't think anyone is working on that particular change, feel free to send a PR and I'll help you out!