Closed BuonOmo closed 1 year ago
What's the next step for this PR? We are waiting for the release of this PR, so that we can use RubyConfig in our production apps. Anything we can help to move the PR to the next stage?
Some context: Our production apps are using an older version of dry-validation
gem.
@teohm same here, I think the most important thing needed is traction and a maintainer discussing it. If you think it needs something from my end as well, please ping me.
I guess you could also use this branch, which would prove that it works fine :) FYI, that is what we do at Stuart
@pkuczynski @cjlarose sorry for the noise, but should I update the PR, do you think you'd be able to review it any time?
@BuonOmo Sorry I dropped the ball on this. This looks great!
What is the experience if someone specifies a validation_contract
instead of using config.schema
as described in the README? Is a runtime check still performed to ensure we're using a compatible version?
Closed in favor of #333
Fixes https://github.com/rubyconfig/config/issues/276
Problem
Having the dependency on a fix dry-validation version generates multiple issues:
Solution
We remove the dependency, but still check at runtime that the dependency is met if and only if the schema validation feature is used.
Other aspects
All of the changes described below are in a separate commit, I can revert it if it helps merging!
Ruby 2.1 compatibility
During the implementation, I had a bug with
Config
reloading. Thelib/config/compatibility.rb
introduces a bug that is really hard to debug (for me at least):Since this file was added for an EOL ruby version (2.1, per commit https://github.com/rubyconfig/config/commit/c4119fb2a31f40759718a0169e2b59a6f86c9aad), I removed it.
Usage of
require_relative
Helps be sure that we talk about the same file! Otherwise, it depends on
$LOAD_PATH
(or$:
)Dir[..].sort.each { require }
Make sure that the require order is not OS, or filesystem dependent
.ruby-version
I've removed the file, as for
Gemfile.lock
, the ruby version will in the end depend on the person using the gem, so developers of the gem should also be able to run it with their local ruby versions!Config::Error
Since there are now two possible errors, lets regroup those under the same banner! (not that it is not a breaking change since
.is_a?
will still behave the same)